Re: feature request: a basic conversation manager

From: Carsten Dominik <dominik@science.uva.nl>
To: Samuel Wales <samologist@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: feature request: a basic conversation manager
Date: Tue, 9 Dec 2008 11:36:36 +0100	[thread overview]
Message-ID: <112E0F16-0177-4B88-9F9B-967F6A6D2507@uva.nl> (raw)
In-Reply-To: <20524da70811261844o3f47782ay3437fdfdc55bda95@mail.gmail.com>

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.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode