"Samuel Wales" writes: > 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.