feature request: a basic conversation manager

feature request: a basic conversation manager

[Samuel Wales]

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

Re: feature request: a basic conversation manager

[Ross Patterson]

[-- Attachment #1: Type: text/plain, Size: 3573 bytes --]

I've had this post flagged since it first appeared and I've been
intending to read it and comment on it fully.  Since I appear not to be
getting around to it, I thought I'd make a brief post for now.  I
haven't read your proposal fully but I've implemented some code that
might be relevant or a related cousin.

I use my cell phone's voice memo capability as a part of my GTD inbox
collection points.  I record brief voice memos when something occurs to
me, they are saved to my phone's microSD card.  Later I export the voice
memos to a special "in" folder on my laptop.  Then I review the memos,
refile them next to whatever org-mode file they apply to, create any new
headlines/TODOs if appropriate, and transcribe them into special notes
on the headline.  To make all this very fast and efficient, I've written
a library called transcribe.el.  I've attached it.

I start by populating the bongo playlist buffer with all the memo files
from my in folder (i f "~/in/phone/sounds/*.qcp") and I play the first
file.  The transcribe.el library provides a global key binding to a
command for moving the currently playing file.  I use that keystroke
once I've heard enough of the memo to refile it to an appropriate
location.  As such, the contents of the "in" folder continually
represent the memos that have not yet been processed even if I'm
interrupted.

I create any appropriate headlines/TODOs for the memo.  Then I use the
org-add-transcription command bound to "C-c v z" to add a special kind
of note to the headline/TODO.  The note is pre-populated with a link to
the memo file and a timestamp for the time the memo was taken if
supported (see below).  I transcribe the memo using a global key binding
for bongo-seek, "C-c v s", as necessary.  When I'm done, I save the note
and use bong-seek again to advance to the next memo.  Then I repeat this
"move, add headlines, transcribe note" cycle until I'm done.

With this approach, I can process my voice memos moving freely around my
org-mode buffers as appropriate and without having to switch to any
bongo buffers, and doing everything from key bindings.  As such, the
only context switches I have to do are directly related to the contexts
of the voice memos themselves.  I find it works quite well for me.

The memo's are *.qcp files in Qualcomm's PureVoice format.  The
transcribe.el library includes a bongo backend to play the PureVoice
filed using Qualcomm's pvconv converter:

    http://www.qctconnect.com/products/purevoice_downloads.html

The backend converts the files to *.wav files next to the original *.qcp
files and plays the *.wav files.  The pvconv converter is pretty fast,
but even so long *.qcp recordings can take a couple seconds to convert
before bongo can start playing the file.  If someone wants to work out
how to convert the *.qcp file asynchronously so that bongo can start
playing the *.wav before pvconv is finished, that would be great.  The
*.qcp files are so much smaller than the converted *.wav files, so the
backend deletes the *.wav file once it stops playing the file.

Phones using Qualcomm's PureVoice memos embed a timestamp into the
filename of the memo.  Currently transcribe.el can extract this
timestamp for use in the transcription note.  I'd be interested in
contributions for extracting timestamps from voice memos that do it
differently.

I'd like to hear any thoughts on this, if this can/should be integrated
with your concept of a conversation manager, or even independent of
that.  I also hope to review your proposal more thoroughly in the near
future.

Ross


[-- Attachment #2: transcribe.el --]
[-- Type: application/emacs-lisp, Size: 10144 bytes --]

[-- Attachment #3: Type: text/plain, Size: 8334 bytes --]


"Samuel Wales" <samologist@gmail.com> 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:
>
>   - <<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.

[-- Attachment #4: Type: text/plain, Size: 204 bytes --]

_______________________________________________
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: Re: feature request: a basic conversation manager

[Samuel Wales]

Hi Ross,

A =conversation= is one interaction or note, so voice memos
are good for entering in a conversation, if that is the
right thing for what you need.  So are scans and anything
else.

Currently you store links with org-add-transcription.  My
copy of org does not have that, but the conversation manager
as designed has a store function.  Unless there is more that
you want to do, you only need to call that.  If remember is
integrated as the input UI for a conversation (which is a
reasonable choice), then a template might allow you to call
your code using %().

The first post in this thread has more detail, and I have other notes
if there is interest.

Hope that's useful.

-- 
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

Re: feature request: a basic conversation manager

[Carsten Dominik]

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

Re: feature request: a basic conversation manager

[Samuel Wales]

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

Re: feature request: a basic conversation manager

[Jambunathan K]

In the context of the original post, is there a possible way to do this.

1. I mark a TODO entry in todo.org as done. 

2. An org-id (say ID-TODO) gets created for the TODO entry if there is
   none yet. 

3. The state transition to DONE triggers a capture rule. The
   conversation is collected in a capture buffer and filed as a heading
   under conversation.org.    An org-id (say ID-CONV) is generated for
   the captured entry. 

4. ID-TODO is noted in the conversation.org
5. ID-CONV is noted down in todo.org

Jambunathan K.

Re: Re: feature request: a basic conversation manager

[Eric S Fraga]

On Thu, 19 Aug 2010 00:31:05 +0530, Jambunathan K <kjambunathan@gmail.com> wrote:
> 
> 
> In the context of the original post, is there a possible way to do this.
> 
> 1. I mark a TODO entry in todo.org as done. 
> 
> 2. An org-id (say ID-TODO) gets created for the TODO entry if there is
>    none yet. 
> 
> 3. The state transition to DONE triggers a capture rule. The
>    conversation is collected in a capture buffer and filed as a heading
>    under conversation.org.    An org-id (say ID-CONV) is generated for
>    the captured entry. 
> 
> 4. ID-TODO is noted in the conversation.org
> 5. ID-CONV is noted down in todo.org
> 
> Jambunathan K.

I guess you could use the org-after-todo-state-change-hook together
with the functionality of org-capture to implement this quite easily?
Of course, this requires some emacs lisp knowledge.

Re: Re: feature request: a basic conversation manager

[Jambunathan K]

[-- Attachment #1: Type: text/plain, Size: 3904 bytes --]


Carsten & Others

    >> In the context of the original post, is there a possible way to do
    >> this.
    >> 
    >> 1. I mark a TODO entry in todo.org as done.
    >> 
    >> 2. An org-id (say ID-TODO) gets created for the TODO entry if
    >> there is none yet.
    >> 
    >> 3. The state transition to DONE triggers a capture rule. The
    >> conversation is collected in a capture buffer and filed as a
    >> heading under conversation.org.  An org-id (say ID-CONV) is
    >> generated for the captured entry.
    >> 
    >> 4. ID-TODO is noted in the conversation.org 5. ID-CONV is noted
    >> down in todo.org
    >> 
    >> Jambunathan K.

    Eric> I guess you could use the org-after-todo-state-change-hook
    Eric> together with the functionality of org-capture to implement
    Eric> this quite easily?  Of course, this requires some emacs lisp
    Eric> knowledge.

Thanks for accepting my earlier two patches on this thread.

I have identified couple of more things that are needed in org core to
support the above workflow. The changes required are minimal but enable
complex workflows.

[Context Switch]
Before I proceed further let me add this - 

The intention of this mail is to share my notes and influence you to
considering adding the needed support in the core. In effect the
attached patch is demo-only and not to be construed as a formal commit
request.
[Back to Original Context]

Needed features are:

1. Support for 'out-of-band' capture: Think of it as a
   org-add-log-setup for capture workflow. This is implemented as part
   of org-capture-setup in the enclosed patch.
 
   Note: Capture and Log Notes workflow are similar.
   + org-capture <=> org-add-log-note: Both of these routines pop-up
     notes buffers.

   + org-capture-finalize <=> org-store-log-note: Both dump the user
     notes to the user-specified position.

   + org-capture-setup <=> org-add-log-setup: Both make a note of the
     notes insertion position for later use. Note that they only setup
     the note taking process and don't by themselves collect or store
     notes.

   In some sense the addition of org-add-log-setup would make Log Notes
   and Org Capture closer together. ie., one can make org-capture
   supplant the simplistic Log Notes.
     
2. Support for chained captures: Think of it as per-capture-rule
   exit-hook. Unlike org-capture-before-finalize-hook (which gets
   invoked in the middle of the capture), this gets called right at
   the fag end of the capture after the capture buffer is saved or
   aborted and window configs are restored.
   
   This is implemented as part of a new :exit element in capture-plist
   in the attached patch.

What you need to do:

1. Apply the attached patch to org-mode.
1. Load conversation.el. 
2. Start with following todo.org entry.

# Sample ~/todo.org

* TODO Talk to someone
  SCHEDULED: <2010-09-08 Wed +1d>
  
3. Do a C-c C-t on the above entry
4. Do C-c C-t  once more.   

See the following magic happen

# TODO.org after 2 C-c C-t (s).

* TODO Talk to someone
  SCHEDULED: <2010-09-08 Wed +1d>
  :PROPERTIES:
  :ID:       47df1dd3-3101-4dda-95df-cac71ae7dcab
  :END:
   [[id:a9664246-f396-4084-abb0-0c2274e409cd][Conversation-199003770]] [2010-08-28 Sat 23:25]
   [[id:ee280862-750e-49ee-b3a4-2cebe655dae8][Conversation-446218316]] [2010-08-28 Sat 23:25]


# Conversation.org after 2 C-c C-t (s).
   
* Conversations

** Conversation-446218316
   :PROPERTIES:
   :ID:       ee280862-750e-49ee-b3a4-2cebe655dae8
   :END:
   TODO Context: [[id:47df1dd3-3101-4dda-95df-cac71ae7dcab][Talk to someone]]

** Conversation-199003770
   :PROPERTIES:
   :ID:       a9664246-f396-4084-abb0-0c2274e409cd
   :END:
   TODO Context: [[id:47df1dd3-3101-4dda-95df-cac71ae7dcab][Talk to someone]]
   
   
I have few more things to share. This after sometime or once you revert
with your comments.
   
Jambunathan K. 


Attachments:


[-- Attachment #2: Unit Test Code --]
[-- Type: text/plain, Size: 1964 bytes --]

;; Use ID for storing links
(setq org-link-to-org-use-id t)

;; trigger a capture on done
(add-hook 'org-after-todo-state-change-hook
	  'my-todo-state-change-hook)

;; DONE on a todo item triggers a capture rule "x"
(defun my-todo-state-change-hook () 
  ""
  (when (member state org-done-keywords)
    (org-capture-setup "x")))

;; org-capture-templates

;; Rule-x does this
;; - creates an entry in conversation.org
;; - saves a link to the parent TODO entry in the new conversation node
;; - exits with a call to my-update-todo-node defun

(setq org-capture-templates
      '(("x" "Create conversation node" entry
	 (file+headline "~/conversation.org" "Conversations")
	 "** Conversation-%(int-to-string (random))\n   TODO Context: %a\n   %?"
	 :prepend t :empty-lines 1
	 :exit (my-update-todo-node))))

;;  my-update-todo-node does this
;; - visits the last captured node (ie, the conversation node)
;; - installs a makeshift capture rule and invokes it
;;
;; makeshift capture rule installs a link to the newly created
;; conversation node in the todo node.

(defun my-update-todo-node ()
  (when (not org-note-abort)
    (let (org-capture-templates)

      (with-current-buffer (marker-buffer org-capture-last-stored-marker)
	(save-excursion
	  (goto-char (marker-position org-capture-last-stored-marker))

	  (setq org-capture-templates
		`(("*" "Makeshift" plain
		   (id ,(my-id-from-id-link (org-capture-get :annotation))) 
		   "   %a %U\n   %?")))
	  (org-capture nil "*"))))))


;; this is a library routine used by makeshift capture rule
(defun my-id-from-id-link (id-link)
  ""
  (let (link type path)

    (when (string-match org-bracket-link-regexp id-link)
      (setq link (match-string-no-properties 1  id-link)))

    (when (and link (string-match org-link-re-with-space3 link))
      (setq type (match-string 1 link) path (match-string 2 link)))

    path))

;; (setq hyperlink "[[id:1766a3bb-d717-4779-ac33-98510ada95aa][Conversations]]")

[-- Attachment #3: patch to org-mode --]
[-- Type: text/plain, Size: 3045 bytes --]

From 01210b9ecf8e72db462639a9f317408f1390e964 Mon Sep 17 00:00:00 2001
From: Jambunathan K <kjambunathan@gmail.com>
Date: Sat, 28 Aug 2010 23:17:39 +0530
Subject: [PATCH] Support for chained captures and 'out of band' captures.

* lisp/org-capture.el (org-capture-setup): Added. Use this to install
a catpture rule that needs to be invoked as part of
post-command-hook. Similar to org-add-log-setup.
(org-capture-last-setup-marker):
(org-capture-last-setup-keys): Added. Installed by org-capture-setup
and used within org-capture.
(org-capture): Modified. Check for a pending org-capture-setup and do
the needful.
(org-capture-finalize): Modified.  Check for :exit properties and
invoke the same. Think of it as a per-capture-rule exit hook.
---
 lisp/org-capture.el |   33 +++++++++++++++++++++++++++++++++
 1 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index e544964..def9975 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -76,6 +76,12 @@
   :tag "Org Capture"
   :group 'org)
 
+(defvar org-capture-last-setup-marker (make-marker)
+  "Marker position installed with `org-capture-setup'.")
+
+(defvar org-capture-last-setup-keys  nil 
+  "Capture keys installed with `org-capture-setup'.")
+
 ;;;###autoload
 (defcustom org-capture-templates nil
   "Templates for the creation of new entries.
@@ -370,6 +376,20 @@ Lisp programs can set KEYS to a string associated with a template in
 `org-capture-templates'.  In this case, interactive selection will be
 bypassed."
   (interactive "P")
+
+  (let ((setup-buf (marker-buffer org-capture-last-setup-marker))
+	(setup-pos (marker-position org-capture-last-setup-marker)))
+
+    (when setup-buf
+      (remove-hook 'post-command-hook 'org-capture)
+  
+      (with-current-buffer setup-buf  
+	(goto-char setup-pos)
+	(setq keys org-capture-last-setup-keys))
+      
+      (move-marker org-capture-last-setup-marker nil)
+      (setq org-capture-last-setup-keys nil)))
+
   (cond
    ((equal goto '(4)) (org-capture-goto-target))
    ((equal goto '(16)) (org-capture-goto-last-stored))
@@ -525,6 +545,9 @@ bypassed."
       (kill-buffer (current-buffer))
       ;; Restore the window configuration before capture
       (set-window-configuration return-wconf))
+
+    (eval (or (org-capture-get :exit)))
+    
     (when abort-note
       (cond
        ((equal abort-note 'clean)
@@ -901,6 +924,16 @@ already gone."
 			   (org-table-current-dline))))
    (t (error "This should not happen"))))
 
+(defun org-capture-setup (keys &optional buffer pos)
+  "Install position and keys for later capture.
+The advised action is invoked as part of `post-command-hook'."
+
+  (move-marker org-capture-last-setup-marker (or pos (point)) buffer)
+  (setq org-capture-last-setup-keys keys)
+
+  (add-hook 'post-command-hook 'org-capture 'append)
+  )
+
 (defun org-capture-bookmark-last-stored-position ()
   "Bookmark the last-captured position."
   (let* ((where (org-capture-get :position-for-last-stored 'local))
-- 
1.7.0.4


[-- Attachment #4: Type: text/plain, Size: 201 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[PATCH 1/2] org-store-link: Return link when invoked from within agenda buffer

[Jambunathan K]

[-- Attachment #1: Type: text/plain, Size: 1075 bytes --]


Carsten, 

Sorry about multiple drops. This post *should* contain the patch.

Summary: 

When I trigger a org-capture, with the cursor positioned on a line in
the agenda buffer, I want the link to the agenda entry to be available
as an annotation (%a) to the capture process. Currently this is broken.

The enclosed patch fixes this.

Setup:

# file todo.org
* TODO Talk to someone
   SCHEDULED: <2010-08-23 Mon>

# org-capture-templates
 ("z" "Conversation" entry
  (file+headline "~/conversation.org" "Conversations")
  "** Note taken on %U\n   %a\n   %?" :prepend t :empty-lines 1)

Steps for reporduction:

1. Restrict agenda to todo.org
2. Do org-agenda
3. Place the cursor on the above todo line
4. Trigger an org-capture for the above capture entry

Examine the entries in conversation.org before/after the patch is
applied. Note the absence/presence of the link to the parent todo entry.

* Conversations

** Note taken on [2010-08-23 Mon 03:58]
   [[file:~/todo.org::*Talk%20to%20someone][Talk to someone]]

** Note taken on [2010-08-23 Mon 03:42]

Jambunathan K.


[-- Attachment #2: Type: text/plain, Size: 1857 bytes --]

From bcceabe70968416fb4540e32c68bfbda76820f9b Mon Sep 17 00:00:00 2001
From: Jambunathan K <kjambunathan@gmail.com>
Date: Sun, 22 Aug 2010 23:36:52 +0530
Subject: [PATCH 1/2] org-store-link: Return link when invoked from within agenda buffer.

* org.el (org-store-link): Return link when invoked non-interactively from
an agenda buffer.

TINYCHANGE
---
 lisp/org.el |   11 ++++++-----
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 366c8dd..5db7aab 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -8218,7 +8218,7 @@ For file links, arg negates `org-context-in-file-links'."
   (org-load-modules-maybe)
   (setq org-store-link-plist nil)  ; reset
   (let ((outline-regexp (org-get-limited-outline-regexp))
-	link cpltxt desc description search txt custom-id)
+	link cpltxt desc description search txt custom-id agenda-link)
     (cond
 
      ((run-hook-with-args-until-success 'org-store-link-functions)
@@ -8250,9 +8250,10 @@ For file links, arg negates `org-context-in-file-links'."
 		   (get-text-property (point) 'org-marker))))
 	(when m
 	  (org-with-point-at m
-	    (if (interactive-p)
-		(call-interactively 'org-store-link)
-	      (org-store-link nil))))))
+	    (setq agenda-link
+		  (if (interactive-p)
+		      (call-interactively 'org-store-link)
+		    (org-store-link nil)))))))
 
      ((eq major-mode 'calendar-mode)
       (let ((cd (calendar-cursor-to-date)))
@@ -8389,7 +8390,7 @@ For file links, arg negates `org-context-in-file-links'."
 			       "::#" custom-id))
 	    (setq org-stored-links
 		  (cons (list link desc) org-stored-links))))
-      (and link (org-make-link-string link desc)))))
+      (or agenda-link (and link (org-make-link-string link desc))))))
 
 (defun org-store-link-props (&rest plist)
   "Store link properties, extract names and addresses."
-- 
1.7.0.4


[-- Attachment #3: Type: text/plain, Size: 201 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Accepted] [Orgmode, 1/2] org-store-link: Return link when invoked from within agenda buffer

[Carsten Dominik]

Patch 239 (http://patchwork.newartisans.com/patch/239/) is now "Accepted".

Maintainer comment: none

This relates to the following submission:

http://mid.gmane.org/%3C81sk26s06x.fsf%40gmail.com%3E

Here is the original message containing the patch:

> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Subject: [Orgmode,
> 	1/2] org-store-link: Return link when invoked from within agenda
> 	buffer
> Date: Mon, 23 Aug 2010 03:37:31 -0000
> From: Jambunathan K <kjambunathan@gmail.com>
> X-Patchwork-Id: 239
> Message-Id: <81sk26s06x.fsf@gmail.com>
> To: emacs-orgmode@gnu.org
> Cc: 
> 
> Carsten, 
> 
> Sorry about multiple drops. This post *should* contain the patch.
> 
> Summary: 
> 
> When I trigger a org-capture, with the cursor positioned on a line in
> the agenda buffer, I want the link to the agenda entry to be available
> as an annotation (%a) to the capture process. Currently this is broken.
> 
> The enclosed patch fixes this.
> 
> Setup:
> 
> # file todo.org
> * TODO Talk to someone
>    SCHEDULED: <2010-08-23 Mon>
> 
> # org-capture-templates
>  ("z" "Conversation" entry
>   (file+headline "~/conversation.org" "Conversations")
>   "** Note taken on %U\n   %a\n   %?" :prepend t :empty-lines 1)
> 
> Steps for reporduction:
> 
> 1. Restrict agenda to todo.org
> 2. Do org-agenda
> 3. Place the cursor on the above todo line
> 4. Trigger an org-capture for the above capture entry
> 
> Examine the entries in conversation.org before/after the patch is
> applied. Note the absence/presence of the link to the parent todo entry.
> 
> * Conversations
> 
> ** Note taken on [2010-08-23 Mon 03:58]
>    [[file:~/todo.org::*Talk%20to%20someone][Talk to someone]]
> 
> ** Note taken on [2010-08-23 Mon 03:42]
> 
> Jambunathan K.
> >From bcceabe70968416fb4540e32c68bfbda76820f9b Mon Sep 17 00:00:00 2001
> From: Jambunathan K <kjambunathan@gmail.com>
> Date: Sun, 22 Aug 2010 23:36:52 +0530
> Subject: [PATCH 1/2] org-store-link: Return link when invoked from within agenda buffer.
> 
> * org.el (org-store-link): Return link when invoked non-interactively from
> an agenda buffer.
> 
> TINYCHANGE
> 
> ---
> lisp/org.el |   11 ++++++-----
>  1 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/lisp/org.el b/lisp/org.el
> index 366c8dd..5db7aab 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -8218,7 +8218,7 @@ For file links, arg negates `org-context-in-file-links'."
>    (org-load-modules-maybe)
>    (setq org-store-link-plist nil)  ; reset
>    (let ((outline-regexp (org-get-limited-outline-regexp))
> -	link cpltxt desc description search txt custom-id)
> +	link cpltxt desc description search txt custom-id agenda-link)
>      (cond
>  
>       ((run-hook-with-args-until-success 'org-store-link-functions)
> @@ -8250,9 +8250,10 @@ For file links, arg negates `org-context-in-file-links'."
>  		   (get-text-property (point) 'org-marker))))
>  	(when m
>  	  (org-with-point-at m
> -	    (if (interactive-p)
> -		(call-interactively 'org-store-link)
> -	      (org-store-link nil))))))
> +	    (setq agenda-link
> +		  (if (interactive-p)
> +		      (call-interactively 'org-store-link)
> +		    (org-store-link nil)))))))
>  
>       ((eq major-mode 'calendar-mode)
>        (let ((cd (calendar-cursor-to-date)))
> @@ -8389,7 +8390,7 @@ For file links, arg negates `org-context-in-file-links'."
>  			       "::#" custom-id))
>  	    (setq org-stored-links
>  		  (cons (list link desc) org-stored-links))))
> -      (and link (org-make-link-string link desc)))))
> +      (or agenda-link (and link (org-make-link-string link desc))))))
>  
>  (defun org-store-link-props (&rest plist)
>    "Store link properties, extract names and addresses."
> 

[PATCH 1/2] org-store-link: Return link when invoked from within agenda buffer

[Jambunathan K]

Summary: 

When I trigger a org-capture, with the cursor positioned on a line in
the agenda buffer, I want the link to the agenda entry to be available
as an annotation (%a) to the capture process. Currently this is broken.

The enclosed patch fixes this.

Setup:

# file todo.org
* TODO Talk to someone
   SCHEDULED: <2010-08-23 Mon>

# org-capture-templates
 ("z" "Conversation" entry
  (file+headline "~/conversation.org" "Conversations")
  "** Note taken on %U\n   %a\n   %?" :prepend t :empty-lines 1)

Steps for reporduction:

1. Restrict agenda to todo.org
2. Do org-agenda
3. Place the cursor on the above todo line
4. Trigger an org-capture for the above capture entry

Examine the entries in conversation.org before/after the patch is
applied. Note the absence/presence of the link to the parent todo entry.

* Conversations

** Note taken on [2010-08-23 Mon 03:58]
   [[file:~/todo.org::*Talk%20to%20someone][Talk to someone]]

** Note taken on [2010-08-23 Mon 03:42]

Jambunathan K.


<#part type="text/plain" buffer=0001-org-store-link-Return-link-when-invoked-from-within-.patch disposition=inline>
<#/part>

[PATCH 1/2] org-store-link: Return link when invoked from within agenda buffer

[Jambunathan K]

Summary: 

When I trigger a org-capture, with the cursor positioned on a line in
the agenda buffer, I want the link to the agenda entry to be available
as an annotation (%a) to the capture process. Currently this is broken.

The enclosed patch fixes this.

Setup:

# file todo.org
* TODO Talk to someone
   SCHEDULED: <2010-08-23 Mon>

# org-capture-templates
 ("z" "Conversation" entry
  (file+headline "~/conversation.org" "Conversations")
  "** Note taken on %U\n   %a\n   %?" :prepend t :empty-lines 1)

Steps for reporduction:

1. Restrict agenda to todo.org
2. Do org-agenda
3. Place the cursor on the above todo line
4. Trigger an org-capture for the above capture entry

Examine the entries in conversation.org before/after the patch is
applied. Note the absence/presence of the link to the parent todo entry.

* Conversations

** Note taken on [2010-08-23 Mon 03:58]
   [[file:~/todo.org::*Talk%20to%20someone][Talk to someone]]

** Note taken on [2010-08-23 Mon 03:42]

Jambunathan K.


<#part type="text/plain" buffer=0001-org-store-link-Return-link-when-invoked-from-within-.patch disposition=inline>
<#/part>

[PATCH 2/2] org-store-link: Fix storing of links to headlines in indirect buffers

[Jambunathan K]

[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]


Summary: 

When org-store-link is invoked on a headline in indirect buffer (as in a
capture buffer), hyperlink gets created to the file and NOT the
headline. This is a bug.

The attached patch fixes this.

Setup:

# ~/.emacs

(defun my-conversation-id ()
  (interactive)

  (remove-hook 'org-capture-before-finalize-hook 'my-conversation-id)

  (let ((org-link-to-org-use-id t))
    (call-interactively 'org-store-link)
    )
  )


# org-capture-templates

 ("x" "Conversations" entry
  (file+headline "~/conversation.org" "Conversations")
  "%(progn (add-hook 'org-capture-before-finalize-hook 'my-conversation-id) \"\")** Note taken on %U\n   %?  " :prepend t :empty-lines 1)

Steps for reproduction:

Trigger org-capture for the above capture entry.

Examine conversation.org before/after the patch is applied. Note the
absence/presence of IDs for the captured entry. 

Check for the stored links using C-c C-l. Note the file/headline links.

# file conversation.org before and after the patch

* Conversations

** Note taken on [2010-08-23 Mon 04:33]
   :PROPERTIES:
   :ID:       7e1974a6-8fa1-43cf-bef3-2adf37d99130
   :END:

** Note taken on [2010-08-23 Mon 04:32]

# (org-insert-link) showing stored links before and after the patch

file:~/conversation.org (file:~/conversation.org)
id:7e1974a6-8fa1-43cf-bef3-2adf37d99130 (Note taken on [2010-08-23 Mon 04:33])


Jambunathan K.


[-- Attachment #2: Type: text/plain, Size: 1872 bytes --]

From 90628b45ee4d270b32f8a56618ca75ceb4a16b21 Mon Sep 17 00:00:00 2001
From: Jambunathan K <kjambunathan@gmail.com>
Date: Mon, 23 Aug 2010 02:32:15 +0530
Subject: [PATCH 2/2] org-store-link: Fix storing of links to headlines in indirect buffers

* org.el (org-store-link): Storing of links to headlines in indirect
buffers was broken.  Fix it.

TINYCHANGE
---
 lisp/org.el |   11 +++++++----
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 5db7aab..15379ef 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -8301,13 +8301,14 @@ For file links, arg negates `org-context-in-file-links'."
  	(setq cpltxt (concat "file:" file)
  	      link (org-make-link cpltxt))))
 
-     ((and buffer-file-name (org-mode-p))
+     ((and (buffer-file-name (buffer-base-buffer)) (org-mode-p))
       (setq custom-id (ignore-errors (org-entry-get nil "CUSTOM_ID")))
       (cond
        ((org-in-regexp "<<\\(.*?\\)>>")
 	(setq cpltxt
 	      (concat "file:"
-		      (abbreviate-file-name buffer-file-name)
+		      (abbreviate-file-name
+		       (buffer-file-name (buffer-base-buffer)))
 		      "::" (match-string 1))
 	      link (org-make-link cpltxt)))
        ((and (featurep 'org-id)
@@ -8329,11 +8330,13 @@ For file links, arg negates `org-context-in-file-links'."
 		     (error
 		      ;; probably before first headline, link to file only
 		      (concat "file:"
-			      (abbreviate-file-name buffer-file-name))))))
+			      (abbreviate-file-name
+			       (buffer-file-name (buffer-base-buffer))))))))
        (t
 	;; Just link to current headline
 	(setq cpltxt (concat "file:"
-			     (abbreviate-file-name buffer-file-name)))
+			     (abbreviate-file-name
+			      (buffer-file-name (buffer-base-buffer)))))
 	;; Add a context search string
 	(when (org-xor org-context-in-file-links arg)
 	  (setq txt (cond
-- 
1.7.0.4


[-- Attachment #3: Type: text/plain, Size: 201 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Accepted] [Orgmode, 2/2] org-store-link: Fix storing of links to headlines in indirect buffers

[Carsten Dominik]

Patch 238 (http://patchwork.newartisans.com/patch/238/) is now "Accepted".

Maintainer comment: none

This relates to the following submission:

http://mid.gmane.org/%3C8162z2tf8n.fsf_-_%40gmail.com%3E

Here is the original message containing the patch:

> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Subject: [Orgmode,
> 	2/2] org-store-link: Fix storing of links to headlines in indirect
> 	buffers
> Date: Mon, 23 Aug 2010 04:11:20 -0000
> From: Jambunathan K <kjambunathan@gmail.com>
> X-Patchwork-Id: 238
> Message-Id: <8162z2tf8n.fsf_-_@gmail.com>
> To: emacs-orgmode@gnu.org
> Cc: 
> 
> Summary: 
> 
> When org-store-link is invoked on a headline in indirect buffer (as in a
> capture buffer), hyperlink gets created to the file and NOT the
> headline. This is a bug.
> 
> The attached patch fixes this.
> 
> Setup:
> 
> # ~/.emacs
> 
> (defun my-conversation-id ()
>   (interactive)
> 
>   (remove-hook 'org-capture-before-finalize-hook 'my-conversation-id)
> 
>   (let ((org-link-to-org-use-id t))
>     (call-interactively 'org-store-link)
>     )
>   )
> 
> 
> # org-capture-templates
> 
>  ("x" "Conversations" entry
>   (file+headline "~/conversation.org" "Conversations")
>   "%(progn (add-hook 'org-capture-before-finalize-hook 'my-conversation-id) \"\")** Note taken on %U\n   %?  " :prepend t :empty-lines 1)
> 
> Steps for reproduction:
> 
> Trigger org-capture for the above capture entry.
> 
> Examine conversation.org before/after the patch is applied. Note the
> absence/presence of IDs for the captured entry. 
> 
> Check for the stored links using C-c C-l. Note the file/headline links.
> 
> # file conversation.org before and after the patch
> 
> * Conversations
> 
> ** Note taken on [2010-08-23 Mon 04:33]
>    :PROPERTIES:
>    :ID:       7e1974a6-8fa1-43cf-bef3-2adf37d99130
>    :END:
> 
> ** Note taken on [2010-08-23 Mon 04:32]
> 
> # (org-insert-link) showing stored links before and after the patch
> 
> file:~/conversation.org (file:~/conversation.org)
> id:7e1974a6-8fa1-43cf-bef3-2adf37d99130 (Note taken on [2010-08-23 Mon 04:33])
> 
> 
> Jambunathan K.
> >From 90628b45ee4d270b32f8a56618ca75ceb4a16b21 Mon Sep 17 00:00:00 2001
> From: Jambunathan K <kjambunathan@gmail.com>
> Date: Mon, 23 Aug 2010 02:32:15 +0530
> Subject: [PATCH 2/2] org-store-link: Fix storing of links to headlines in indirect buffers
> 
> * org.el (org-store-link): Storing of links to headlines in indirect
> buffers was broken.  Fix it.
> 
> TINYCHANGE
> 
> ---
> lisp/org.el |   11 +++++++----
>  1 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/lisp/org.el b/lisp/org.el
> index 5db7aab..15379ef 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -8301,13 +8301,14 @@ For file links, arg negates `org-context-in-file-links'."
>   	(setq cpltxt (concat "file:" file)
>   	      link (org-make-link cpltxt))))
>  
> -     ((and buffer-file-name (org-mode-p))
> +     ((and (buffer-file-name (buffer-base-buffer)) (org-mode-p))
>        (setq custom-id (ignore-errors (org-entry-get nil "CUSTOM_ID")))
>        (cond
>         ((org-in-regexp "<<\\(.*?\\)>>")
>  	(setq cpltxt
>  	      (concat "file:"
> -		      (abbreviate-file-name buffer-file-name)
> +		      (abbreviate-file-name
> +		       (buffer-file-name (buffer-base-buffer)))
>  		      "::" (match-string 1))
>  	      link (org-make-link cpltxt)))
>         ((and (featurep 'org-id)
> @@ -8329,11 +8330,13 @@ For file links, arg negates `org-context-in-file-links'."
>  		     (error
>  		      ;; probably before first headline, link to file only
>  		      (concat "file:"
> -			      (abbreviate-file-name buffer-file-name))))))
> +			      (abbreviate-file-name
> +			       (buffer-file-name (buffer-base-buffer))))))))
>         (t
>  	;; Just link to current headline
>  	(setq cpltxt (concat "file:"
> -			     (abbreviate-file-name buffer-file-name)))
> +			     (abbreviate-file-name
> +			      (buffer-file-name (buffer-base-buffer)))))
>  	;; Add a context search string
>  	(when (org-xor org-context-in-file-links arg)
>  	  (setq txt (cond
> 

Re: feature request: a basic conversation manager

[Samuel Wales]

Hi K,

Indeed, if that is what you want to do, you can do it without too much
effort, I think.  The conversation manager is a bit different, but
similar.

I have not looked at the conversation manager idea for some time.  At
the time I also wrote (and still have) more notes on it.  If anybody
is interested in the conversation manager, let me know.

There are many future possibilities for the conversation manager.

===> But please note the following <===

The most important thing is that in the meantime I came up with the
idea of ID markers, which actually significantly simplify these issues
and allow a large set of other possibilities, simultaneously.

So, if what you are doing is similar to the conversation manager (as
opposed to org-add-note or tweaks to allow capture to capture to
point, for example), then I think it is best for me to dredge out my
notes on ID markers (but you can visit my posts on them and get the
main idea).  My health is not up to doing a lot on it now, however, so
I would just post what I already did.

If what you are doing is different, such as getting org-capture to
capture to point, then it's probably not relevant.

Hope this helps.

Samuel

On 2010-08-18, Jambunathan K <kjambunathan@gmail.com> wrote:
>
> In the context of the original post, is there a possible way to do this.
>
> 1. I mark a TODO entry in todo.org as done.
>
> 2. An org-id (say ID-TODO) gets created for the TODO entry if there is
>    none yet.
>
> 3. The state transition to DONE triggers a capture rule. The
>    conversation is collected in a capture buffer and filed as a heading
>    under conversation.org.    An org-id (say ID-CONV) is generated for
>    the captured entry.
>
> 4. ID-TODO is noted in the conversation.org
> 5. ID-CONV is noted down in todo.org
>
> Jambunathan K.
>
>
>
>
>


-- 
Q: How many CDC "scientists" does it take to change a lightbulb?
A: "You only think it's dark." [CDC has denied a deadly disease for 25 years]
==========
Retrovirus: http://www.wpinstitute.org/xmrv/index.html -- PLEASE DONATE
===
PNAS must publish the original Lo and Alter NIH/FDA XMRV paper
verbatim along with the new paper.

Re: feature request: a basic conversation manager

[Samuel Wales]

More clearly:

  1) The conversation manager is basically superseded by the ID
markers idea.  That is, you can implement it trivially once ID markers
are implemented.
  2) What you are doing is not related to the conversation manager.

On 2010-08-28, Samuel Wales <samologist@gmail.com> wrote:
> Hi K,
>
> Indeed, if that is what you want to do, you can do it without too much
> effort, I think.  The conversation manager is a bit different, but
> similar.
>
> I have not looked at the conversation manager idea for some time.  At
> the time I also wrote (and still have) more notes on it.  If anybody
> is interested in the conversation manager, let me know.
>
> There are many future possibilities for the conversation manager.
>
> ===> But please note the following <===
>
> The most important thing is that in the meantime I came up with the
> idea of ID markers, which actually significantly simplify these issues
> and allow a large set of other possibilities, simultaneously.
>
> So, if what you are doing is similar to the conversation manager (as
> opposed to org-add-note or tweaks to allow capture to capture to
> point, for example), then I think it is best for me to dredge out my
> notes on ID markers (but you can visit my posts on them and get the
> main idea).  My health is not up to doing a lot on it now, however, so
> I would just post what I already did.
>
> If what you are doing is different, such as getting org-capture to
> capture to point, then it's probably not relevant.
>
> Hope this helps.
>
> Samuel
>
> On 2010-08-18, Jambunathan K <kjambunathan@gmail.com> wrote:
>>
>> In the context of the original post, is there a possible way to do this.
>>
>> 1. I mark a TODO entry in todo.org as done.
>>
>> 2. An org-id (say ID-TODO) gets created for the TODO entry if there is
>>    none yet.
>>
>> 3. The state transition to DONE triggers a capture rule. The
>>    conversation is collected in a capture buffer and filed as a heading
>>    under conversation.org.    An org-id (say ID-CONV) is generated for
>>    the captured entry.
>>
>> 4. ID-TODO is noted in the conversation.org
>> 5. ID-CONV is noted down in todo.org
>>
>> Jambunathan K.
>>
>>
>>
>>
>>
>
>
> --
> Q: How many CDC "scientists" does it take to change a lightbulb?
> A: "You only think it's dark." [CDC has denied a deadly disease for 25
> years]
> ==========
> Retrovirus: http://www.wpinstitute.org/xmrv/index.html -- PLEASE DONATE
> ===
> PNAS must publish the original Lo and Alter NIH/FDA XMRV paper
> verbatim along with the new paper.
>


-- 
Q: How many CDC "scientists" does it take to change a lightbulb?
A: "You only think it's dark." [CDC has denied a deadly serious
disease for 25 years]
==========
Retrovirus: http://www.wpinstitute.org/xmrv/index.html -- PLEASE DONATE
===
I would like to see the original Lo et al. 2010 NIH/FDA XMRV paper.

Re: feature request: a basic conversation manager

[Jambunathan K]

Samuel

    Samuel> What you are doing is not related to the conversation
    Samuel> manager.

I never claimed otherwise.

My use-case was clearly laid out and my patches are consistent with the
purpose stated in the original post.

If your concern is that I shouldn't be hijacking the subject line+thread
(and/or dilute it with non-core items), I totally respect that. I
promise to be careful next time.

Hope this settles things :-).

Jambunathan K.

Re: feature request: a basic conversation manager

[Samuel Wales]

I'm not upset about anything.  Just didn't want anybody to be confused.
It seemed to me that you thought that what you were doing was related,
that's all.

On 2010-08-28, Jambunathan K <kjambunathan@gmail.com> wrote:
>
> Samuel
>
>     Samuel> What you are doing is not related to the conversation
>     Samuel> manager.
>
> I never claimed otherwise.
>
> My use-case was clearly laid out and my patches are consistent with the
> purpose stated in the original post.
>
> If your concern is that I shouldn't be hijacking the subject line+thread
> (and/or dilute it with non-core items), I totally respect that. I
> promise to be careful next time.
>
> Hope this settles things :-).
>
> Jambunathan K.
>


-- 
Q: How many CDC "scientists" does it take to change a lightbulb?
A: "You only think it's dark." [CDC has denied a deadly serious
disease for 25 years]
==========
Retrovirus: http://www.wpinstitute.org/xmrv/index.html -- PLEASE DONATE
===
I would like to see the original Lo et al. 2010 NIH/FDA XMRV paper.