emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] feature request: a basic conversation manager


From: Carsten Dominik
Subject: Re: [Orgmode] feature request: a basic conversation manager
Date: Tue, 9 Dec 2008 11:36:36 +0100

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:

 - <<here is a solution>>.  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.

   - <<drawer design>>:

     - 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 <<org-id design>>, 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.
address@hidden
http://lists.gnu.org/mailman/listinfo/emacs-orgmode





reply via email to

[Prev in Thread] Current Thread [Next in Thread]