From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: feature request: a basic conversation manager Date: Tue, 9 Dec 2008 11:36:36 +0100 Message-ID: <112E0F16-0177-4B88-9F9B-967F6A6D2507@uva.nl> References: <20524da70811261844o3f47782ay3437fdfdc55bda95@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L9zxK-000397-0o for emacs-orgmode@gnu.org; Tue, 09 Dec 2008 05:36:42 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L9zxJ-00038j-GA for emacs-orgmode@gnu.org; Tue, 09 Dec 2008 05:36:41 -0500 Received: from [199.232.76.173] (port=52651 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L9zxI-00038e-VI for emacs-orgmode@gnu.org; Tue, 09 Dec 2008 05:36:41 -0500 Received: from ug-out-1314.google.com ([66.249.92.175]:47917) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L9zxI-0003wQ-8w for emacs-orgmode@gnu.org; Tue, 09 Dec 2008 05:36:40 -0500 Received: by ug-out-1314.google.com with SMTP id 36so1356620uga.17 for ; Tue, 09 Dec 2008 02:36:38 -0800 (PST) In-Reply-To: <20524da70811261844o3f47782ay3437fdfdc55bda95@mail.gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Samuel Wales Cc: emacs-orgmode@gnu.org Hi Samuel, I have now read through your proposal. To me it seems that using ID's is the best way forward. Right now I am working on (in fact have for some time) to greatly improve the usability of Entry ID's, in particular: - Keeping the location of ID's in a hash, for fast access - Writing this hash to disk when exiting Emacs - Keeping track of locations during cut and paste - Tools to check for consistency, to make sure no ID has been duplicated. - Tools to re-create the hash from scratch, by scanning agenda files and other files known/suspected to contain IDs. - Allowing to create a link *to* a remember item: If you create a remember entry, put a link to it into the kill ring or maybe into the org-store-link. With ID's you can even do this in advance, before storing the note, because the ID is a unique identifier that will find the note wherever you will finally store it. One these are in place, collecting the text from a number of entries listed by ID, or using sparse-tree techniques to expose a number of entries identified by a list of ID's will be easy. I expect the improved OD code to be in 6.15, a which point we can return to your proposals. - Carsten On Nov 27, 2008, at 3:44 AM, Samuel Wales wrote: > This took months to write, but only to be specific in the > spirit of the "how you can help" discussion. The idea and > feature request are relatively simple. > > To skip the preamble, search for [[here is a solution]]. > > A =conversation manager= is focused on phone conversations, > transcripts, letters, journal entries, etc. A > =conversation= is one interaction or note. > > The idea is to keep a global record of conversations of a > certain kind (e.g. phone calls to insurance companies or > doctors) while also keeping that information easily > accessible in the various org places where it belongs. > > Some history: > > Before I started using org, I kept a record of all medical > conversations in a file. This provided a time-sorted place > to look for conversations. I'll call this a =journal=, > after Carsten's usage in the manual. > > I also had a todo file for data (e.g. phone numbers, people > to talk to about x), unfinished tasks (e.g. get insurance > company 1 to see reason, see doctor 1), etc. This was an > indented plain text file in emacs. I will call the org > equivalent =todo.org=. > > I copied back and forth. > > I want to do better than that with org, because org-mode is > powerful. > > Here are some problems with using todo.org to keep > conversations and notes together: > > 1. The journal doesn't have all conversations; some are > in todo.org unless I only use one consistently. > > 2. todo.org grows and extraneous information is in there. > > 3. The notes are scattered over todo.org. For example, I > might have a call to a doctor, and put that note under > the todo item to call that doctor. But that is bad > when I want all medical phone calls in order. > > 4. I want conversations accessible from more than one > place. For example, if the conversation is under > doctor 1, I also want it under the medical issue and > possibly elsewhere, without duplication. > > 5. The journal doesn't have its entries in order, because > I might add something else later that happened > earlier, if I copy to journal from todo. > > 6. The todo.org notes are out of time order (i.e. the > first conversation in the buffer is not necessarily > the first conversation). > > 7. Except for metadata, conversations should be out of > sight until they need to be looked up. > > Of the many solutions that come to mind, here are a few that > I believe will *not* work: > > 1. Using ordinary links is not a solution, because you > would have to click on each link to see only one > conversation. Also, you couldn't isearch all > conversations at the same time. > > 2. Advising org-log-note to copy the note to the journal > duplicates stuff. That means that grep will find > things in 2 places. Also, it doesn't handle the > question of notes that should be attached to more than > one item. Duplication is a disaster, IMO. > > 3. Keeping the notes scattered in todo.org precludes > access to the journal outside org (e.g. if your > computer crashes and you need to get the journal from > your backups on a computer that does not run emacs), > doesn't handle notes that should be attached to more > than one item, keeps unnecessary stuff there, and > increases the size of the org file. > > Here is a solution that I believe will work: > > - <>. If you are on the doctor 1 > headline in todo.org, you run a command that shows all > conversations with that doctor in a single buffer. > > The conversations are stored only in the journal. A > single place for all medical conversations that is still > accessible from todo.org. > > Here is a design using drawers. See below for a > different design using org-id's that I think will be > better. This one is to illustrate the concept. > > - <>: > > - Each todo.org heading that has conversations gets > a list that is like the CLOCK interval list, > except that it contains links to conversations > (I.e. journal entries). > > todo.org: > > * doctor 1 > :CONVERSATION: > CONVERSATION: [2007-10-27 Sat 13:55] medical-journal.org > CONVERSATION: [2008-12-01 Mon 16:10] medical-journal.org > \:END: > ** phone number is ... > * insurance company 1 > :CONVERSATION: > CONVERSATION: [2007-07-05 Thu 12:00] medical-journal.org > CONVERSATION: [2008-12-01 Mon 16:10] medical-journal.org > CONVERSATION: [2009-12-02 Wed 17:15] medical-journal.org > \:END: > ** talk to soandso > > (Perhaps the links would be actual links.) > > - A command (perhaps c-c c-c) gathers the > conversations into a buffer. > > - To start a new conversation, a command inserts a > link into todo.org and an entry in the journal. > > - The medical journal: > > * [2007-10-27 Sat 13:55] > called mary at doctor 1's office about our appointment. > ... > * [2007-11-05 Mon 16:05] > called doctor 2 about issue 1. nobody was in. > > - The links below the todo.org headline give you an > idea of when you have called doctor 1 without having > to keep the actual conversations in todo.org. > > Here is the other design: > > - A different design, the <>, is > arguably simpler, and I like it better: > > - Every journaled task gets a list of org-id's. > - Each id refers to a conversation in the journal > file. > - Then we gather conversations using org-id's. > > Here are my comments on the org-id design: > > - This is a more general solution. It will work for > more than just conversations. There are interesting > possibilities here. > - For backward links, we do the same in reverse, thus > gathering the todo.org tasks that are related to the > conversation. The code is the same. I'd recommend > doing this by default. > - This design does not show you the list of > timestamps. That is a drawback. > - This might be solved by putting the target > headline over the org-id as an overlay. For > conversations, the target headline is simply the > start timestamp. For future applications, it > can be anything. > > Here are some comments on the solution in general (either > of the designs). > > - Some comments: > - There appear to be no archiving or expiry issues > with this solution. > - Here are 3 possible ways to create the buffer that > contains the collected conversations. > > 1. Create a read-only buffer. > 2. Have it actually be the journal buffer via > folding or possibly via hiding. > 3. Pass editing to the journal buffer a la grep mode > or the org agenda. > > IMO, #2 would be ideal for the user. > - Automatic journaling to another task also > - It would be useful to specify that anything > journaled below a place in the outline hierarchy > should always also be journaled to that place. > - A simple tag, :journal:, would work nicely. > - In "/medical/doctors/doctor 1", talking to doctor > 1 also saves the conversation link to medical if > and only if you put that tag on medical. If you > do not have the tag on anything, then the > conversation will only be connected with doctor 1. > - It might be useful to specify under "doctor 1" that > it and anything below it should always also be > journaled to "insurance company 1". This might > require an org-id for the target, which is another > argument for org-id's, since we would do that anyway > to go backward. > - Of course, if you just want to use org-add-note to > store a regular note, you can. > > For me, this functionality would make org simpler to use. > > Comments? > > I have notes on future possibilities in case there is > interest. > > Thanks. > > -- > Myalgic encephalomyelitis denialists are knowingly causing further > suffering and death by opposing biomedical research on this serious > infectious disease. Do you care about the world? > http://www.meactionuk.org.uk/What_Is_ME_What_Is_CFS.htm > > > _______________________________________________ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode