Re: [Orgmode] feature request: a basic conversation manager
Hi Carsten, Thank you very much! I left out mention of hashes, etc. to make the idea simple :). -- 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
Re: [Orgmode] feature request: a basic conversation manager
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. - <>: - E
[Orgmode] feature request: a basic conversation manager
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 li