A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?)

A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?)

[Samuel Wales]

Hi Carsten,

Here is an idea for a much simpler remember architecture that
simultaneously solves Alan's problem.

  1) To me also, a more complicated way to deal with
     remember buffers feels wrong.
  2) If there is more than one thing you are working on, the
     power of the org hierarchy feels like the best way to
     keep track.

  3) The current remember probably does not do what Alan
     wants, even with a better workflow.
     - What if you want to remember from remember?
     - It feels complicated to finalize the old idea and go
       there, then remember the new one, then finish the old
       one, then go back to where you were.  Maybe we can
       simplify.
     - When you've finished the old one, you want to restore
       context to before the old idea.  This is probably
       impossible.  The stack is blown.
  4) Other issues:
     - If you forget to finalize, you lose data.
     - It is easy to reflexively call remember from remember,
       making you surprised that the old idea disappeared.
     - You might forget that you had the old idea.
       Especially if you are having short-term memory issues
       or are distracted.

  5) Here is my idea: discard the concept of remember
     buffers entirely.
     - Create the entry at the target location when you call
       org-remember.
     - Employ a virtual buffer to narrow to the created
       entry.

  6) Some benefits:
     1) Alan can remember, then remember again, then
        remember a third time without having to save
        remember buffers or name them (which he would need).
     2) Your idea is where it should be.  If you want
        context, you simply remove the narrowing.
     3) org has access to the target buffer's buffer-local
        variables, org variables, encoding and multilingual
        settings of the target, etc.
     4) Auto-save saves to a place where Emacs will pick it
        up again if Emacs crashes.
     5) A backup directory is no longer necessary to restore
        data from a killed (remember) buffer.
     6) Finalizing is no longer a matter of losing your data
        if you forget.  It merely pops windows.

  7) If you still want the concept of "I am not done
     remembering this remember," add a tag (:REMEMBERING:)
     at creation time and have org-remember-finalize remove
     that tag.  To see in-progress remembers, call the
     agenda on that tag.

  8) This eases yak shaving.
     - http://www.catb.org/~esr/jargon/html/Y/yak-shaving.html
     - This is a simple way to keep track of what you were
       doing when you remember from remember.
     - I recommend making org-remember-finalize use a
       /stack/, so that successive invocations recreate the
       previous window/buffer context until they get to the
       original context.
     - I think that we intuitively work in stacks.  This
       lets us avoid overloading our own memory.
     - If Emacs crashes, the worst thing that will happen is
       that you end up with a bunch of :REMEMBERING: tasks
       around your org files.  Not lost data.

To summarize, the current remember naturally leads to the
need for increasing workarounds, and therefore requests for
features, which leads to more complexity.  By leveraging the
power of the org hierarchy, we can simplify, and get yak
shaving support as a nice surprise benefit.

Let me know what you think.


On Tue, Sep 29, 2009 at 02:37, Carsten Dominik
<carsten.dominik@gmail.com> wrote:
> Hi Allen,
>
> saving remember buffers is hackish and complex as it is, so I am not going
> to add this option.
>
> I think the workflow has to be this:
>
> Create a remember buffer and more-or-less immediately file it.
>
> If you need to work on the content for a longer time, work on it at the
> target location:  Simply exit remember with C-u C-c C-c.  The buffer will be
> filed and the target location will be visited immediately.  So now you can
> work there as long as you want, and start another remember process when you
> need one.
>
> HTH
>
> - Carsten
>
> On Sep 9, 2009, at 10:17 PM, Alan E. Davis wrote:
>
>> I've looked briefly into the org-remember.el.  A hook exists:
>> remember-mode-hook.  Im not sure it can be successfully applied to the case
>> I envision.
>>
>> THere are tradeoffs to immediately saving a remember buffer to a file, and
>> editing a note in the remember buffer, then saving with  remember-finalize.
>>  I don't remember what they are, as they led me away from immediately saving
>> quite a while ago. I was strongly encouraged by the establishment of a
>> procedure to automatically save to a directory, any remember buffer that was
>> not finallized.  I had some issues with it, including how clunky it was to
>> recover, and it was broken at some point, when I was too busy to fix it.
>>
>> One problem with editing in the Remember buffer, then saving later, is
>> forgetting where I am.  I can rely on several remember templates, and too
>> often have lost the remember buffer's contents, when I ran remember again.
>>
>> What I propose is the make it possible---optionally---to invoke a hook to
>> save existing remember buffers when C-c C-r (X) is used to file a remember
>> note while in the remember buffer already.
>>
>> I found a test "bufferp".  It does not seem to recognize the buffer name
>> "Remember", nor "*Remember*".
>>
>> Is it possible to do this, or is remember going to defeat this?
>>
>>
>> Alan Davis
>>
>> You can know the name of a bird in all the languages of the world,  but
>> when you're finished, you'll know absolutely nothing whatever about the
>> bird... So let's look at the bird and see what it's doing---that's what
>> counts.
>>
>>   ----Richard Feynman
>>
>>
>>
>> On Wed, Sep 9, 2009 at 3:42 PM, Alan E. Davis <lngndvs@gmail.com> wrote:
>> Is there a hook to save the remember buffer when I type C-c C-r when I'm
>> in an unsaved remember buffer?  That would be almost as good, perhaps
>> better, than saving the remember buffer to a special file or directory.
>>
>>
>> Alan
>>
>> You can know the name of a bird in all the languages of the world,  but
>> when you're finished, you'll know absolutely nothing whatever about the
>> bird... So let's look at the bird and see what it's doing---that's what
>> counts.
>>
>>   ----Richard Feynman
>>
>>
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> 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
>



-- 
Myalgic encephalomyelitis causes death (Jason et al. 2006)
and severe suffering.  Conflicts of interest are destroying
research.  What people "know" is wrong.  Silence = death.
http://www.meactionuk.org.uk/What_Is_ME_What_Is_CFS.htm

Re: A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?)

[Eric S Fraga, Eric S Fraga]

At Tue, 29 Sep 2009 13:48:53 -0700,
Samuel Wales wrote:
> 
> Hi Carsten,
> 
> Here is an idea for a much simpler remember architecture that
> simultaneously solves Alan's problem.

[...]

>   5) Here is my idea: discard the concept of remember
>      buffers entirely.
>      - Create the entry at the target location when you call
>        org-remember.
>      - Employ a virtual buffer to narrow to the created
>        entry.

I like this.  Just yesterday, I was in the process of "remembering"
something when somebody came by my office.  I talked to the person
and, during the conversation, I had the need to "remember" something
that came up.  However, I was already in a remember buffer which was
partially completed.  I had to finalise this before I could start a
new remember and this interrupted the discussion I was having with my
colleague.

Your approach would have worked perfectly yesterday!

Re: A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?)

[Carsten Dominik]

I don't know what the others think....

... but I think this is a brilliant idea.

- Carsten

On Sep 29, 2009, at 10:48 PM, Samuel Wales wrote:

> Hi Carsten,
>
> Here is an idea for a much simpler remember architecture that
> simultaneously solves Alan's problem.
>
>  1) To me also, a more complicated way to deal with
>     remember buffers feels wrong.
>  2) If there is more than one thing you are working on, the
>     power of the org hierarchy feels like the best way to
>     keep track.
>
>  3) The current remember probably does not do what Alan
>     wants, even with a better workflow.
>     - What if you want to remember from remember?
>     - It feels complicated to finalize the old idea and go
>       there, then remember the new one, then finish the old
>       one, then go back to where you were.  Maybe we can
>       simplify.
>     - When you've finished the old one, you want to restore
>       context to before the old idea.  This is probably
>       impossible.  The stack is blown.
>  4) Other issues:
>     - If you forget to finalize, you lose data.
>     - It is easy to reflexively call remember from remember,
>       making you surprised that the old idea disappeared.
>     - You might forget that you had the old idea.
>       Especially if you are having short-term memory issues
>       or are distracted.
>
>  5) Here is my idea: discard the concept of remember
>     buffers entirely.
>     - Create the entry at the target location when you call
>       org-remember.
>     - Employ a virtual buffer to narrow to the created
>       entry.
>
>  6) Some benefits:
>     1) Alan can remember, then remember again, then
>        remember a third time without having to save
>        remember buffers or name them (which he would need).
>     2) Your idea is where it should be.  If you want
>        context, you simply remove the narrowing.
>     3) org has access to the target buffer's buffer-local
>        variables, org variables, encoding and multilingual
>        settings of the target, etc.
>     4) Auto-save saves to a place where Emacs will pick it
>        up again if Emacs crashes.
>     5) A backup directory is no longer necessary to restore
>        data from a killed (remember) buffer.
>     6) Finalizing is no longer a matter of losing your data
>        if you forget.  It merely pops windows.
>
>  7) If you still want the concept of "I am not done
>     remembering this remember," add a tag (:REMEMBERING:)
>     at creation time and have org-remember-finalize remove
>     that tag.  To see in-progress remembers, call the
>     agenda on that tag.
>
>  8) This eases yak shaving.
>     - http://www.catb.org/~esr/jargon/html/Y/yak-shaving.html
>     - This is a simple way to keep track of what you were
>       doing when you remember from remember.
>     - I recommend making org-remember-finalize use a
>       /stack/, so that successive invocations recreate the
>       previous window/buffer context until they get to the
>       original context.
>     - I think that we intuitively work in stacks.  This
>       lets us avoid overloading our own memory.
>     - If Emacs crashes, the worst thing that will happen is
>       that you end up with a bunch of :REMEMBERING: tasks
>       around your org files.  Not lost data.
>
> To summarize, the current remember naturally leads to the
> need for increasing workarounds, and therefore requests for
> features, which leads to more complexity.  By leveraging the
> power of the org hierarchy, we can simplify, and get yak
> shaving support as a nice surprise benefit.
>
> Let me know what you think.
>
>
> On Tue, Sep 29, 2009 at 02:37, Carsten Dominik
> <carsten.dominik@gmail.com> wrote:
>> Hi Allen,
>>
>> saving remember buffers is hackish and complex as it is, so I am  
>> not going
>> to add this option.
>>
>> I think the workflow has to be this:
>>
>> Create a remember buffer and more-or-less immediately file it.
>>
>> If you need to work on the content for a longer time, work on it at  
>> the
>> target location:  Simply exit remember with C-u C-c C-c.  The  
>> buffer will be
>> filed and the target location will be visited immediately.  So now  
>> you can
>> work there as long as you want, and start another remember process  
>> when you
>> need one.
>>
>> HTH
>>
>> - Carsten
>>
>> On Sep 9, 2009, at 10:17 PM, Alan E. Davis wrote:
>>
>>> I've looked briefly into the org-remember.el.  A hook exists:
>>> remember-mode-hook.  Im not sure it can be successfully applied to  
>>> the case
>>> I envision.
>>>
>>> THere are tradeoffs to immediately saving a remember buffer to a  
>>> file, and
>>> editing a note in the remember buffer, then saving with  remember- 
>>> finalize.
>>>  I don't remember what they are, as they led me away from  
>>> immediately saving
>>> quite a while ago. I was strongly encouraged by the establishment  
>>> of a
>>> procedure to automatically save to a directory, any remember  
>>> buffer that was
>>> not finallized.  I had some issues with it, including how clunky  
>>> it was to
>>> recover, and it was broken at some point, when I was too busy to  
>>> fix it.
>>>
>>> One problem with editing in the Remember buffer, then saving  
>>> later, is
>>> forgetting where I am.  I can rely on several remember templates,  
>>> and too
>>> often have lost the remember buffer's contents, when I ran  
>>> remember again.
>>>
>>> What I propose is the make it possible---optionally---to invoke a  
>>> hook to
>>> save existing remember buffers when C-c C-r (X) is used to file a  
>>> remember
>>> note while in the remember buffer already.
>>>
>>> I found a test "bufferp".  It does not seem to recognize the  
>>> buffer name
>>> "Remember", nor "*Remember*".
>>>
>>> Is it possible to do this, or is remember going to defeat this?
>>>
>>>
>>> Alan Davis
>>>
>>> You can know the name of a bird in all the languages of the  
>>> world,  but
>>> when you're finished, you'll know absolutely nothing whatever  
>>> about the
>>> bird... So let's look at the bird and see what it's doing---that's  
>>> what
>>> counts.
>>>
>>>   ----Richard Feynman
>>>
>>>
>>>
>>> On Wed, Sep 9, 2009 at 3:42 PM, Alan E. Davis <lngndvs@gmail.com>  
>>> wrote:
>>> Is there a hook to save the remember buffer when I type C-c C-r  
>>> when I'm
>>> in an unsaved remember buffer?  That would be almost as good,  
>>> perhaps
>>> better, than saving the remember buffer to a special file or  
>>> directory.
>>>
>>>
>>> Alan
>>>
>>> You can know the name of a bird in all the languages of the  
>>> world,  but
>>> when you're finished, you'll know absolutely nothing whatever  
>>> about the
>>> bird... So let's look at the bird and see what it's doing---that's  
>>> what
>>> counts.
>>>
>>>   ----Richard Feynman
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>>
>> _______________________________________________
>> 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
>>
>
>
>
> -- 
> Myalgic encephalomyelitis causes death (Jason et al. 2006)
> and severe suffering.  Conflicts of interest are destroying
> research.  What people "know" is wrong.  Silence = death.
> http://www.meactionuk.org.uk/What_Is_ME_What_Is_CFS.htm

Re: A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?)

[Tim O'Callaghan]

+1, can we keep/have:
- the templates,
- possibility to 'pick file/topic first then remember'
- 'throw it into the bucket for later'.
- org - remember keymap
- local fontification?
- remove need to have remember package installed?

Tim.

2009/9/30 Carsten Dominik <carsten.dominik@gmail.com>:
> I don't know what the others think....
>
> ... but I think this is a brilliant idea.
>
> - Carsten
>
> On Sep 29, 2009, at 10:48 PM, Samuel Wales wrote:
>
>> Hi Carsten,
>>
>> Here is an idea for a much simpler remember architecture that
>> simultaneously solves Alan's problem.
>>
>>  1) To me also, a more complicated way to deal with
>>    remember buffers feels wrong.
>>  2) If there is more than one thing you are working on, the
>>    power of the org hierarchy feels like the best way to
>>    keep track.
>>
>>  3) The current remember probably does not do what Alan
>>    wants, even with a better workflow.
>>    - What if you want to remember from remember?
>>    - It feels complicated to finalize the old idea and go
>>      there, then remember the new one, then finish the old
>>      one, then go back to where you were.  Maybe we can
>>      simplify.
>>    - When you've finished the old one, you want to restore
>>      context to before the old idea.  This is probably
>>      impossible.  The stack is blown.
>>  4) Other issues:
>>    - If you forget to finalize, you lose data.
>>    - It is easy to reflexively call remember from remember,
>>      making you surprised that the old idea disappeared.
>>    - You might forget that you had the old idea.
>>      Especially if you are having short-term memory issues
>>      or are distracted.
>>
>>  5) Here is my idea: discard the concept of remember
>>    buffers entirely.
>>    - Create the entry at the target location when you call
>>      org-remember.
>>    - Employ a virtual buffer to narrow to the created
>>      entry.
>>
>>  6) Some benefits:
>>    1) Alan can remember, then remember again, then
>>       remember a third time without having to save
>>       remember buffers or name them (which he would need).
>>    2) Your idea is where it should be.  If you want
>>       context, you simply remove the narrowing.
>>    3) org has access to the target buffer's buffer-local
>>       variables, org variables, encoding and multilingual
>>       settings of the target, etc.
>>    4) Auto-save saves to a place where Emacs will pick it
>>       up again if Emacs crashes.
>>    5) A backup directory is no longer necessary to restore
>>       data from a killed (remember) buffer.
>>    6) Finalizing is no longer a matter of losing your data
>>       if you forget.  It merely pops windows.
>>
>>  7) If you still want the concept of "I am not done
>>    remembering this remember," add a tag (:REMEMBERING:)
>>    at creation time and have org-remember-finalize remove
>>    that tag.  To see in-progress remembers, call the
>>    agenda on that tag.
>>
>>  8) This eases yak shaving.
>>    - http://www.catb.org/~esr/jargon/html/Y/yak-shaving.html
>>    - This is a simple way to keep track of what you were
>>      doing when you remember from remember.
>>    - I recommend making org-remember-finalize use a
>>      /stack/, so that successive invocations recreate the
>>      previous window/buffer context until they get to the
>>      original context.
>>    - I think that we intuitively work in stacks.  This
>>      lets us avoid overloading our own memory.
>>    - If Emacs crashes, the worst thing that will happen is
>>      that you end up with a bunch of :REMEMBERING: tasks
>>      around your org files.  Not lost data.
>>
>> To summarize, the current remember naturally leads to the
>> need for increasing workarounds, and therefore requests for
>> features, which leads to more complexity.  By leveraging the
>> power of the org hierarchy, we can simplify, and get yak
>> shaving support as a nice surprise benefit.
>>
>> Let me know what you think.
>>
>>
>> On Tue, Sep 29, 2009 at 02:37, Carsten Dominik
>> <carsten.dominik@gmail.com> wrote:
>>>
>>> Hi Allen,
>>>
>>> saving remember buffers is hackish and complex as it is, so I am not
>>> going
>>> to add this option.
>>>
>>> I think the workflow has to be this:
>>>
>>> Create a remember buffer and more-or-less immediately file it.
>>>
>>> If you need to work on the content for a longer time, work on it at the
>>> target location:  Simply exit remember with C-u C-c C-c.  The buffer will
>>> be
>>> filed and the target location will be visited immediately.  So now you
>>> can
>>> work there as long as you want, and start another remember process when
>>> you
>>> need one.
>>>
>>> HTH
>>>
>>> - Carsten
>>>
>>> On Sep 9, 2009, at 10:17 PM, Alan E. Davis wrote:
>>>
>>>> I've looked briefly into the org-remember.el.  A hook exists:
>>>> remember-mode-hook.  Im not sure it can be successfully applied to the
>>>> case
>>>> I envision.
>>>>
>>>> THere are tradeoffs to immediately saving a remember buffer to a file,
>>>> and
>>>> editing a note in the remember buffer, then saving with
>>>>  remember-finalize.
>>>>  I don't remember what they are, as they led me away from immediately
>>>> saving
>>>> quite a while ago. I was strongly encouraged by the establishment of a
>>>> procedure to automatically save to a directory, any remember buffer that
>>>> was
>>>> not finallized.  I had some issues with it, including how clunky it was
>>>> to
>>>> recover, and it was broken at some point, when I was too busy to fix it.
>>>>
>>>> One problem with editing in the Remember buffer, then saving later, is
>>>> forgetting where I am.  I can rely on several remember templates, and
>>>> too
>>>> often have lost the remember buffer's contents, when I ran remember
>>>> again.
>>>>
>>>> What I propose is the make it possible---optionally---to invoke a hook
>>>> to
>>>> save existing remember buffers when C-c C-r (X) is used to file a
>>>> remember
>>>> note while in the remember buffer already.
>>>>
>>>> I found a test "bufferp".  It does not seem to recognize the buffer name
>>>> "Remember", nor "*Remember*".
>>>>
>>>> Is it possible to do this, or is remember going to defeat this?
>>>>
>>>>
>>>> Alan Davis
>>>>
>>>> You can know the name of a bird in all the languages of the world,  but
>>>> when you're finished, you'll know absolutely nothing whatever about the
>>>> bird... So let's look at the bird and see what it's doing---that's what
>>>> counts.
>>>>
>>>>  ----Richard Feynman
>>>>
>>>>
>>>>
>>>> On Wed, Sep 9, 2009 at 3:42 PM, Alan E. Davis <lngndvs@gmail.com> wrote:
>>>> Is there a hook to save the remember buffer when I type C-c C-r when I'm
>>>> in an unsaved remember buffer?  That would be almost as good, perhaps
>>>> better, than saving the remember buffer to a special file or directory.
>>>>
>>>>
>>>> Alan
>>>>
>>>> You can know the name of a bird in all the languages of the world,  but
>>>> when you're finished, you'll know absolutely nothing whatever about the
>>>> bird... So let's look at the bird and see what it's doing---that's what
>>>> counts.
>>>>
>>>>  ----Richard Feynman
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>>
>> --
>> Myalgic encephalomyelitis causes death (Jason et al. 2006)
>> and severe suffering.  Conflicts of interest are destroying
>> research.  What people "know" is wrong.  Silence = death.
>> 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: A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?)

[Carsten Dominik]

On Sep 30, 2009, at 4:45 PM, Tim O'Callaghan wrote:

> +1, can we keep/have:
> - the templates,

yes

> - possibility to 'pick file/topic first then remember'

No. The idea would be that you refile then or later.

> - 'throw it into the bucket for later'.

what does that mean?

> - org - remember keymap

Why do you need this?

> - local fontification?

Why do you need this?

> - remove need to have remember package installed?

That need does not exist even now.

- Carsten

>
> Tim.
>
> 2009/9/30 Carsten Dominik <carsten.dominik@gmail.com>:
>> I don't know what the others think....
>>
>> ... but I think this is a brilliant idea.
>>
>> - Carsten
>>
>> On Sep 29, 2009, at 10:48 PM, Samuel Wales wrote:
>>
>>> Hi Carsten,
>>>
>>> Here is an idea for a much simpler remember architecture that
>>> simultaneously solves Alan's problem.
>>>
>>>  1) To me also, a more complicated way to deal with
>>>    remember buffers feels wrong.
>>>  2) If there is more than one thing you are working on, the
>>>    power of the org hierarchy feels like the best way to
>>>    keep track.
>>>
>>>  3) The current remember probably does not do what Alan
>>>    wants, even with a better workflow.
>>>    - What if you want to remember from remember?
>>>    - It feels complicated to finalize the old idea and go
>>>      there, then remember the new one, then finish the old
>>>      one, then go back to where you were.  Maybe we can
>>>      simplify.
>>>    - When you've finished the old one, you want to restore
>>>      context to before the old idea.  This is probably
>>>      impossible.  The stack is blown.
>>>  4) Other issues:
>>>    - If you forget to finalize, you lose data.
>>>    - It is easy to reflexively call remember from remember,
>>>      making you surprised that the old idea disappeared.
>>>    - You might forget that you had the old idea.
>>>      Especially if you are having short-term memory issues
>>>      or are distracted.
>>>
>>>  5) Here is my idea: discard the concept of remember
>>>    buffers entirely.
>>>    - Create the entry at the target location when you call
>>>      org-remember.
>>>    - Employ a virtual buffer to narrow to the created
>>>      entry.
>>>
>>>  6) Some benefits:
>>>    1) Alan can remember, then remember again, then
>>>       remember a third time without having to save
>>>       remember buffers or name them (which he would need).
>>>    2) Your idea is where it should be.  If you want
>>>       context, you simply remove the narrowing.
>>>    3) org has access to the target buffer's buffer-local
>>>       variables, org variables, encoding and multilingual
>>>       settings of the target, etc.
>>>    4) Auto-save saves to a place where Emacs will pick it
>>>       up again if Emacs crashes.
>>>    5) A backup directory is no longer necessary to restore
>>>       data from a killed (remember) buffer.
>>>    6) Finalizing is no longer a matter of losing your data
>>>       if you forget.  It merely pops windows.
>>>
>>>  7) If you still want the concept of "I am not done
>>>    remembering this remember," add a tag (:REMEMBERING:)
>>>    at creation time and have org-remember-finalize remove
>>>    that tag.  To see in-progress remembers, call the
>>>    agenda on that tag.
>>>
>>>  8) This eases yak shaving.
>>>    - http://www.catb.org/~esr/jargon/html/Y/yak-shaving.html
>>>    - This is a simple way to keep track of what you were
>>>      doing when you remember from remember.
>>>    - I recommend making org-remember-finalize use a
>>>      /stack/, so that successive invocations recreate the
>>>      previous window/buffer context until they get to the
>>>      original context.
>>>    - I think that we intuitively work in stacks.  This
>>>      lets us avoid overloading our own memory.
>>>    - If Emacs crashes, the worst thing that will happen is
>>>      that you end up with a bunch of :REMEMBERING: tasks
>>>      around your org files.  Not lost data.
>>>
>>> To summarize, the current remember naturally leads to the
>>> need for increasing workarounds, and therefore requests for
>>> features, which leads to more complexity.  By leveraging the
>>> power of the org hierarchy, we can simplify, and get yak
>>> shaving support as a nice surprise benefit.
>>>
>>> Let me know what you think.
>>>
>>>
>>> On Tue, Sep 29, 2009 at 02:37, Carsten Dominik
>>> <carsten.dominik@gmail.com> wrote:
>>>>
>>>> Hi Allen,
>>>>
>>>> saving remember buffers is hackish and complex as it is, so I am  
>>>> not
>>>> going
>>>> to add this option.
>>>>
>>>> I think the workflow has to be this:
>>>>
>>>> Create a remember buffer and more-or-less immediately file it.
>>>>
>>>> If you need to work on the content for a longer time, work on it  
>>>> at the
>>>> target location:  Simply exit remember with C-u C-c C-c.  The  
>>>> buffer will
>>>> be
>>>> filed and the target location will be visited immediately.  So  
>>>> now you
>>>> can
>>>> work there as long as you want, and start another remember  
>>>> process when
>>>> you
>>>> need one.
>>>>
>>>> HTH
>>>>
>>>> - Carsten
>>>>
>>>> On Sep 9, 2009, at 10:17 PM, Alan E. Davis wrote:
>>>>
>>>>> I've looked briefly into the org-remember.el.  A hook exists:
>>>>> remember-mode-hook.  Im not sure it can be successfully applied  
>>>>> to the
>>>>> case
>>>>> I envision.
>>>>>
>>>>> THere are tradeoffs to immediately saving a remember buffer to a  
>>>>> file,
>>>>> and
>>>>> editing a note in the remember buffer, then saving with
>>>>>  remember-finalize.
>>>>>  I don't remember what they are, as they led me away from  
>>>>> immediately
>>>>> saving
>>>>> quite a while ago. I was strongly encouraged by the  
>>>>> establishment of a
>>>>> procedure to automatically save to a directory, any remember  
>>>>> buffer that
>>>>> was
>>>>> not finallized.  I had some issues with it, including how clunky  
>>>>> it was
>>>>> to
>>>>> recover, and it was broken at some point, when I was too busy to  
>>>>> fix it.
>>>>>
>>>>> One problem with editing in the Remember buffer, then saving  
>>>>> later, is
>>>>> forgetting where I am.  I can rely on several remember  
>>>>> templates, and
>>>>> too
>>>>> often have lost the remember buffer's contents, when I ran  
>>>>> remember
>>>>> again.
>>>>>
>>>>> What I propose is the make it possible---optionally---to invoke  
>>>>> a hook
>>>>> to
>>>>> save existing remember buffers when C-c C-r (X) is used to file a
>>>>> remember
>>>>> note while in the remember buffer already.
>>>>>
>>>>> I found a test "bufferp".  It does not seem to recognize the  
>>>>> buffer name
>>>>> "Remember", nor "*Remember*".
>>>>>
>>>>> Is it possible to do this, or is remember going to defeat this?
>>>>>
>>>>>
>>>>> Alan Davis
>>>>>
>>>>> You can know the name of a bird in all the languages of the  
>>>>> world,  but
>>>>> when you're finished, you'll know absolutely nothing whatever  
>>>>> about the
>>>>> bird... So let's look at the bird and see what it's doing--- 
>>>>> that's what
>>>>> counts.
>>>>>
>>>>>  ----Richard Feynman
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Sep 9, 2009 at 3:42 PM, Alan E. Davis  
>>>>> <lngndvs@gmail.com> wrote:
>>>>> Is there a hook to save the remember buffer when I type C-c C-r  
>>>>> when I'm
>>>>> in an unsaved remember buffer?  That would be almost as good,  
>>>>> perhaps
>>>>> better, than saving the remember buffer to a special file or  
>>>>> directory.
>>>>>
>>>>>
>>>>> Alan
>>>>>
>>>>> You can know the name of a bird in all the languages of the  
>>>>> world,  but
>>>>> when you're finished, you'll know absolutely nothing whatever  
>>>>> about the
>>>>> bird... So let's look at the bird and see what it's doing--- 
>>>>> that's what
>>>>> counts.
>>>>>
>>>>>  ----Richard Feynman
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Myalgic encephalomyelitis causes death (Jason et al. 2006)
>>> and severe suffering.  Conflicts of interest are destroying
>>> research.  What people "know" is wrong.  Silence = death.
>>> 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: A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?)

[Tim O'Callaghan]

> - 'throw it into the bucket for later'.
>
> what does that mean?

Kind of works as remember now. Currently you have a 'default save to
point' for a particular template. I would guess that most people just
throw it all into the one 'bucket' and sort it out later.

>
>> - org - remember keymap
>
> Why do you need this?

I don't use the C-0-, C-1, whatever. I have my own keys mapped for the
remember buffer. I use C-X c-s for org-remember-finalize for example,
which may cause conflicts.

>
>> - local fontification?
>
> Why do you need this?

I plan on expanding on the 'keeping me honest' idea, Which i am still
working on and will turn into a contrib. I want to use fontification
for "malformed" headings etc as warnings in unfilled remember
templates. For example, to highlight an empty/malformed effort
property. I suspect it would be easier, and faster to apply on a
per-template/buffer basis, rather than the whole org-file.

>
>> - remove need to have remember package installed?
>
> That need does not exist even now.
>

I was having trouble recently with a lack of remember. A problem in my
config, which I've just fixed. Thanks for pointing it out.

Possibly make remember editing a minor mode? That would allow for any
extra keymaps and fonrification and such wouldn't it?

Tim.

> - Carsten
>
>>
>> Tim.
>>
>> 2009/9/30 Carsten Dominik <carsten.dominik@gmail.com>:
>>>
>>> I don't know what the others think....
>>>
>>> ... but I think this is a brilliant idea.
>>>
>>> - Carsten
>>>
>>> On Sep 29, 2009, at 10:48 PM, Samuel Wales wrote:
>>>
>>>> Hi Carsten,
>>>>
>>>> Here is an idea for a much simpler remember architecture that
>>>> simultaneously solves Alan's problem.
>>>>
>>>>  1) To me also, a more complicated way to deal with
>>>>   remember buffers feels wrong.
>>>>  2) If there is more than one thing you are working on, the
>>>>   power of the org hierarchy feels like the best way to
>>>>   keep track.
>>>>
>>>>  3) The current remember probably does not do what Alan
>>>>   wants, even with a better workflow.
>>>>   - What if you want to remember from remember?
>>>>   - It feels complicated to finalize the old idea and go
>>>>     there, then remember the new one, then finish the old
>>>>     one, then go back to where you were.  Maybe we can
>>>>     simplify.
>>>>   - When you've finished the old one, you want to restore
>>>>     context to before the old idea.  This is probably
>>>>     impossible.  The stack is blown.
>>>>  4) Other issues:
>>>>   - If you forget to finalize, you lose data.
>>>>   - It is easy to reflexively call remember from remember,
>>>>     making you surprised that the old idea disappeared.
>>>>   - You might forget that you had the old idea.
>>>>     Especially if you are having short-term memory issues
>>>>     or are distracted.
>>>>
>>>>  5) Here is my idea: discard the concept of remember
>>>>   buffers entirely.
>>>>   - Create the entry at the target location when you call
>>>>     org-remember.
>>>>   - Employ a virtual buffer to narrow to the created
>>>>     entry.
>>>>
>>>>  6) Some benefits:
>>>>   1) Alan can remember, then remember again, then
>>>>      remember a third time without having to save
>>>>      remember buffers or name them (which he would need).
>>>>   2) Your idea is where it should be.  If you want
>>>>      context, you simply remove the narrowing.
>>>>   3) org has access to the target buffer's buffer-local
>>>>      variables, org variables, encoding and multilingual
>>>>      settings of the target, etc.
>>>>   4) Auto-save saves to a place where Emacs will pick it
>>>>      up again if Emacs crashes.
>>>>   5) A backup directory is no longer necessary to restore
>>>>      data from a killed (remember) buffer.
>>>>   6) Finalizing is no longer a matter of losing your data
>>>>      if you forget.  It merely pops windows.
>>>>
>>>>  7) If you still want the concept of "I am not done
>>>>   remembering this remember," add a tag (:REMEMBERING:)
>>>>   at creation time and have org-remember-finalize remove
>>>>   that tag.  To see in-progress remembers, call the
>>>>   agenda on that tag.
>>>>
>>>>  8) This eases yak shaving.
>>>>   - http://www.catb.org/~esr/jargon/html/Y/yak-shaving.html
>>>>   - This is a simple way to keep track of what you were
>>>>     doing when you remember from remember.
>>>>   - I recommend making org-remember-finalize use a
>>>>     /stack/, so that successive invocations recreate the
>>>>     previous window/buffer context until they get to the
>>>>     original context.
>>>>   - I think that we intuitively work in stacks.  This
>>>>     lets us avoid overloading our own memory.
>>>>   - If Emacs crashes, the worst thing that will happen is
>>>>     that you end up with a bunch of :REMEMBERING: tasks
>>>>     around your org files.  Not lost data.
>>>>
>>>> To summarize, the current remember naturally leads to the
>>>> need for increasing workarounds, and therefore requests for
>>>> features, which leads to more complexity.  By leveraging the
>>>> power of the org hierarchy, we can simplify, and get yak
>>>> shaving support as a nice surprise benefit.
>>>>
>>>> Let me know what you think.
>>>>
>>>>
>>>> On Tue, Sep 29, 2009 at 02:37, Carsten Dominik
>>>> <carsten.dominik@gmail.com> wrote:
>>>>>
>>>>> Hi Allen,
>>>>>
>>>>> saving remember buffers is hackish and complex as it is, so I am not
>>>>> going
>>>>> to add this option.
>>>>>
>>>>> I think the workflow has to be this:
>>>>>
>>>>> Create a remember buffer and more-or-less immediately file it.
>>>>>
>>>>> If you need to work on the content for a longer time, work on it at the
>>>>> target location:  Simply exit remember with C-u C-c C-c.  The buffer
>>>>> will
>>>>> be
>>>>> filed and the target location will be visited immediately.  So now you
>>>>> can
>>>>> work there as long as you want, and start another remember process when
>>>>> you
>>>>> need one.
>>>>>
>>>>> HTH
>>>>>
>>>>> - Carsten
>>>>>
>>>>> On Sep 9, 2009, at 10:17 PM, Alan E. Davis wrote:
>>>>>
>>>>>> I've looked briefly into the org-remember.el.  A hook exists:
>>>>>> remember-mode-hook.  Im not sure it can be successfully applied to the
>>>>>> case
>>>>>> I envision.
>>>>>>
>>>>>> THere are tradeoffs to immediately saving a remember buffer to a file,
>>>>>> and
>>>>>> editing a note in the remember buffer, then saving with
>>>>>>  remember-finalize.
>>>>>>  I don't remember what they are, as they led me away from immediately
>>>>>> saving
>>>>>> quite a while ago. I was strongly encouraged by the establishment of a
>>>>>> procedure to automatically save to a directory, any remember buffer
>>>>>> that
>>>>>> was
>>>>>> not finallized.  I had some issues with it, including how clunky it
>>>>>> was
>>>>>> to
>>>>>> recover, and it was broken at some point, when I was too busy to fix
>>>>>> it.
>>>>>>
>>>>>> One problem with editing in the Remember buffer, then saving later, is
>>>>>> forgetting where I am.  I can rely on several remember templates, and
>>>>>> too
>>>>>> often have lost the remember buffer's contents, when I ran remember
>>>>>> again.
>>>>>>
>>>>>> What I propose is the make it possible---optionally---to invoke a hook
>>>>>> to
>>>>>> save existing remember buffers when C-c C-r (X) is used to file a
>>>>>> remember
>>>>>> note while in the remember buffer already.
>>>>>>
>>>>>> I found a test "bufferp".  It does not seem to recognize the buffer
>>>>>> name
>>>>>> "Remember", nor "*Remember*".
>>>>>>
>>>>>> Is it possible to do this, or is remember going to defeat this?
>>>>>>
>>>>>>
>>>>>> Alan Davis
>>>>>>
>>>>>> You can know the name of a bird in all the languages of the world,
>>>>>>  but
>>>>>> when you're finished, you'll know absolutely nothing whatever about
>>>>>> the
>>>>>> bird... So let's look at the bird and see what it's doing---that's
>>>>>> what
>>>>>> counts.
>>>>>>
>>>>>>  ----Richard Feynman
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 9, 2009 at 3:42 PM, Alan E. Davis <lngndvs@gmail.com>
>>>>>> wrote:
>>>>>> Is there a hook to save the remember buffer when I type C-c C-r when
>>>>>> I'm
>>>>>> in an unsaved remember buffer?  That would be almost as good, perhaps
>>>>>> better, than saving the remember buffer to a special file or
>>>>>> directory.
>>>>>>
>>>>>>
>>>>>> Alan
>>>>>>
>>>>>> You can know the name of a bird in all the languages of the world,
>>>>>>  but
>>>>>> when you're finished, you'll know absolutely nothing whatever about
>>>>>> the
>>>>>> bird... So let's look at the bird and see what it's doing---that's
>>>>>> what
>>>>>> counts.
>>>>>>
>>>>>>  ----Richard Feynman
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Myalgic encephalomyelitis causes death (Jason et al. 2006)
>>>> and severe suffering.  Conflicts of interest are destroying
>>>> research.  What people "know" is wrong.  Silence = death.
>>>> 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: A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?)

[Sebastian Rose]

Yes, good concept.


> yes
>
>> - possibility to 'pick file/topic first then remember'
>
> No. The idea would be that you refile then or later.


No problem for me. I don't remember a case, when I had to change the
tempalte or target after filling it.

And still, there is `org-remember-goto-last-stored' as well as the
option to always go there after finalizing.



  Sebastian

Re: A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?)

[Jean-Marie Gaillourdet]

Hi,

while we are discussing a new org-remember facility. I've been missing
an option to clock the time I've taken to write down my remember note.
E.g. I use remember to make a small protocoll of a telephone call or
some discussion with a colleague. It would help me alot to if that
time would be clocked automatically. 

After the remember note is finalized the previous cloked in task
should become active again. Perhaps with some kind of optional
message/popup/whatever to say: Well, you were doing this before, I
clocked you in again.

It would be even cooler to have a per template flag saying the clock
information should be written into a new headline at some other place.
This would allow to have a log of all remembering actions, that is
separated from the log of the task which were created during
remembering.

I hope this makes sense for someone else as well.

-- Jean-Marie

Re: A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?)

[Rainer Stengele]

Jean-Marie Gaillourdet schrieb:
> Hi,
> 
> while we are discussing a new org-remember facility. I've been missing
> an option to clock the time I've taken to write down my remember note.
> E.g. I use remember to make a small protocoll of a telephone call or
> some discussion with a colleague. It would help me alot to if that
> time would be clocked automatically. 
> 
> After the remember note is finalized the previous cloked in task
> should become active again. Perhaps with some kind of optional
> message/popup/whatever to say: Well, you were doing this before, I
> clocked you in again.
> 
> It would be even cooler to have a per template flag saying the clock
> information should be written into a new headline at some other place.
> This would allow to have a log of all remembering actions, that is
> separated from the log of the task which were created during
> remembering.
> 
> I hope this makes sense for someone else as well.
> 
> -- Jean-Marie
> 
> 
> 
> _______________________________________________
> 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
> 

Hi,

exactly what I am doing quite often!
Being interrupted (telephone, colleague bringing more work ...) while 
working on an clocked in TODO I pop up a remember buffer, manually clock 
in, discuss/write down my stuff, save the remember buffer and then have 
to find the old task.
Yes, "C-u C-c C-x C-j" shows you the recent clcoked in tasks but 
automising the clocking in/out work would make the "remembering" of new 
tasks just faster.

Rainer

Re: Re: A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?)

[Peter Frings]

On 01 Oct 2009, at 11:14, Rainer Stengele wrote:

> Jean-Marie Gaillourdet schrieb:
>> Hi,
>> while we are discussing a new org-remember facility. I've been  
>> missing
>> an option to clock the time I've taken to write down my remember  
>> note.
>> E.g. I use remember to make a small protocoll of a telephone call or
>> some discussion with a colleague. It would help me alot to if that
>> time would be clocked automatically. After the remember note is  
>> finalized the previous cloked in task
>> should become active again. Perhaps with some kind of optional
>> message/popup/whatever to say: Well, you were doing this before, I
>> clocked you in again.
>
[snip]

> exactly what I am doing quite often!
> Being interrupted (telephone, colleague bringing more work ...)  
> while working on an clocked in TODO I pop up a remember buffer,  
> manually clock in, discuss/write down my stuff, save the remember  
> buffer and then have to find the old task.
> Yes, "C-u C-c C-x C-j" shows you the recent clcoked in tasks but  
> automising the clocking in/out work would make the "remembering" of  
> new tasks just faster.


I could image a `clock out and return to the previous one' would be  
handy, even out of the remember facility. Nested activities would be  
great! Of course, one could always mis-use remember for that (if the  
previous feature get implemented, that is), but it feels more  
convenient to have nested clocks.


Cheers,
Peter.

Re: A simpler remember architecture

[Bernt Hansen]

Rainer Stengele <rainer.stengele@online.de> writes:

> Jean-Marie Gaillourdet schrieb:
>> while we are discussing a new org-remember facility. I've been missing
>> an option to clock the time I've taken to write down my remember note.
>> E.g. I use remember to make a small protocoll of a telephone call or
>> some discussion with a colleague. It would help me alot to if that
>> time would be clocked automatically. 
>>
>> After the remember note is finalized the previous cloked in task
>> should become active again. Perhaps with some kind of optional
>> message/popup/whatever to say: Well, you were doing this before, I
>> clocked you in again.
>>
>> It would be even cooler to have a per template flag saying the clock
>> information should be written into a new headline at some other place.
>> This would allow to have a log of all remembering actions, that is
>> separated from the log of the task which were created during
>> remembering.

<snip>

> exactly what I am doing quite often!
> Being interrupted (telephone, colleague bringing more work ...) while
> working on an clocked in TODO I pop up a remember buffer, manually
> clock in, discuss/write down my stuff, save the remember buffer and
> then have to find the old task.
> Yes, "C-u C-c C-x C-j" shows you the recent clcoked in tasks but
> automising the clocking in/out work would make the "remembering" of
> new tasks just faster.

C-u C-c C-x C-i i

Should clock in the interrupted task.  Then I use org-clock-goto to get
to it quickly (which is bound to F11 for me)

HTH,
-Bernt

Re: A simpler remember architecture

[Jean-Marie Gaillourdet]

Hi,

At Thu, 01 Oct 2009 14:41:39 -0400,
Bernt Hansen wrote:
> C-u C-c C-x C-i i

Perhaps, it's worth considering shorter and easier to remember
keyboard shortcuts.

> Should clock in the interrupted task.  Then I use org-clock-goto to get
> to it quickly (which is bound to F11 for me)

Does this work in the remember buffer or after the remember buffer is
finalized?

Best regards,
Jean-Marie

Re: A simpler remember architecture

[Bernt Hansen]

Jean-Marie Gaillourdet <jmg@gaillourdet.net> writes:

> Hi,
>
> At Thu, 01 Oct 2009 14:41:39 -0400,
> Bernt Hansen wrote:
>> C-u C-c C-x C-i i
>
> Perhaps, it's worth considering shorter and easier to remember
> keyboard shortcuts.
>
>> Should clock in the interrupted task.  Then I use org-clock-goto to get
>> to it quickly (which is bound to F11 for me)
>
> Does this work in the remember buffer or after the remember buffer is
> finalized?

Try it.  Yes it works fine.  Don't forget to save your remember buffer
before you start a new one though.

-Bernt

Re: Re: A simpler remember architecture

[David Bremner]

Jean-Marie Gaillourdet wrote:

>At Thu, 01 Oct 2009 14:41:39 -0400,
>Bernt Hansen wrote:
>> C-u C-c C-x C-i i

>Perhaps, it's worth considering shorter and easier to remember
>keyboard shortcuts.

It is actually not quite as bad is it sounds.

- C-u is the generic "do it differently prefix" 

- C-c C-x C-i is the usual start the clock in org.  Unfortunately org
has so many commands, that it is probably hard to find a two key
sequence.

At that point a menu pops up, and you choose i.

d

Re: A simpler remember architecture

[Daniel Clemente]

Some idea about remember variations:

> +1, can we keep/have:
> - the templates,
> - possibility to 'pick file/topic first then remember'

  Actually what I would find useful is a task dispatcher for Emacs: a way to go to common tasks with a few keys.
  For instance: C-c C-x C-g would open your customized dispatcher, a dialog similar to C-u C-c C-x C-j (clock recent task) but which shows you predefined tasks, like:

[1] answer phone
[b] breakfast
[p] procrastinate!
[n] think about next task to do
[2] work on file2 a bit more

  Each key would bring you to the current buffer and task (e.g.: C-c C-x C-g b would move point to the „*** breakfast“ line in minor_tasks.org. 
  Clocking would be 1 chord away: C-c C-x C-g b C-c C-x C-i

  In fact this dispatcher could be a generic file/task/anything dispatcher for Emacs, which could bring you to any file you wanted in a few keys. Like recentf, but with user-defined positions instead of automatically computed entries.

  It could be nice have this inside Org.

-- Daniel

Re: Re: A simpler remember architecture

[Alan E. Davis]

[-- Attachment #1.1: Type: text/plain, Size: 2125 bytes --]

 I've been watching this thread closely.  At this point I want to jump in.
I like the ideas that have been posted here so far, about a different way of
organizing remember in org.  I'm not completely certain, but it seems that
part of what was asked for earlier is included in org-remember already, when
the template posts to the file directly, bypassing the remember buffer
altogether.  I don't remember why this was unfavorable to me, but in many
ways it is useful.  Many of the ideas of the OP and others about the use of
tags, etc., would be more than useful.

Another point, although somewhat off topic, draws my attention:

On Tue, Oct 6, 2009 at 9:41 AM, Daniel Clemente <n142857@gmail.com> wrote:

>
>  Actually what I would find useful is a task dispatcher for Emacs: a way to
> go to common tasks with a few keys.
>  For instance: C-c C-x C-g would open your customized dispatcher, a dialog
> similar to C-u C-c C-x C-j (clock recent task) but which shows you
> predefined tasks, like:
>
> [1] answer phone
> [b] breakfast
> [p] procrastinate!
> [n] think about next task to do
> [2] work on file2 a bit more
>
>
I agree with this, but I'm not sure how I would want it implemented.

I am currently using a file I have called "general.org" with links to
various projects.  Following an idea from Sacha Chua, the following is in
the init file:

   :(defun general ()
   :  (interactive)
   :  (find-file "~/org/General.org"))

I use it to store links to various projects.  It has often occurred to me
how handy it would be if this were integrated better with org-mode.  I would
like to be able to start defining a project, with a command that did the
following (at least):

   1.  interactively ask for a project name and make an org file or
directory (optionally)
   2.  insert a link either in some list like general.org
   3.  define (perhaps suggesting a default) key binding
   4.  perhaps setting up logging or other automatic processes (clocking?)

For now, however, general.org in my setup solves my problem.  One more
reason I like having my ~/org hierarchy under git control on three machines.

 Alan Davis

[-- Attachment #1.2: Type: text/html, Size: 2652 bytes --]

[-- Attachment #2: 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: A simpler remember architecture

[Daniel Clemente]

  Just another off-topic but however related...:

> C-u C-c C-x C-i i
>

  What if C-u C-c C-x C-i could show, in addition to the recently
clocked tasks, some fixed tasks from a user-defined list?
  The dialog would be:

Common tasks:
[1] answer phone
[b] breakfast
[p] procrastinate!
[n] think about next task to do
[2] work on file2 a bit more
Recently clocked in tasks:
[a] working on this
[b] working on that


  That list of common tasks could even be progressively created from
statistics of the most commonly clocked tasks.


-- Daniel

Re: Re: A simpler remember architecture

[Bernt Hansen]

Daniel Clemente <n142857@gmail.com> writes:

>   Just another off-topic but however related...:
>
>> C-u C-c C-x C-i i
>>
>
>   What if C-u C-c C-x C-i could show, in addition to the recently
> clocked tasks, some fixed tasks from a user-defined list?
>   The dialog would be:
>
> Common tasks:
> [1] answer phone
> [b] breakfast
> [p] procrastinate!
> [n] think about next task to do
> [2] work on file2 a bit more
> Recently clocked in tasks:
> [a] working on this
> [b] working on that
>
>
>   That list of common tasks could even be progressively created from
> statistics of the most commonly clocked tasks.

I just use my STARTED agenda view for this.  I have a small number of
tasks in STARTED state for conveniently looking up what to clock in.  It
doesn't have a single keystroke access but the list is short enough that
I find it convenient to use.

I don't think we should pollute the recent clock list with other common
tasks.  If this is really needed then I think it would be better to be a
separate list so we don't have to share key sequence combinations etc.

-Bernt

Re: Re: A simpler remember architecture

[Carsten Dominik]

On Oct 6, 2009, at 1:32 PM, Bernt Hansen wrote:

> Daniel Clemente <n142857@gmail.com> writes:
>
>>  Just another off-topic but however related...:
>>
>>> C-u C-c C-x C-i i
>>>
>>
>>  What if C-u C-c C-x C-i could show, in addition to the recently
>> clocked tasks, some fixed tasks from a user-defined list?
>>  The dialog would be:
>>
>> Common tasks:
>> [1] answer phone
>> [b] breakfast
>> [p] procrastinate!
>> [n] think about next task to do
>> [2] work on file2 a bit more
>> Recently clocked in tasks:
>> [a] working on this
>> [b] working on that
>>
>>
>>  That list of common tasks could even be progressively created from
>> statistics of the most commonly clocked tasks.
>
> I just use my STARTED agenda view for this.  I have a small number of
> tasks in STARTED state for conveniently looking up what to clock  
> in.  It
> doesn't have a single keystroke access but the list is short enough  
> that
> I find it convenient to use.
>
> I don't think we should pollute the recent clock list with other  
> common
> tasks.  If this is really needed then I think it would be better to  
> be a
> separate list so we don't have to share key sequence combinations etc.

I agree.

To cater more to the OP's needs, consider using a special tag for such
common tasks, like :COMMON:

The create a special agenda view hat just shows this tag.

- Carsten

Re: Re: A simpler remember architecture

[Daniel Clemente]

>
> To cater more to the OP's needs, consider using a special tag for such
> common tasks, like :COMMON:
>
> The create a special agenda view hat just shows this tag.


  This is a very nice solution. I thought of the agenda view as a way
to view your agenda, but now I see that it can actually serve as a
generic task dispatcher.

  There are also common files and directories which I often want to
open. I will write them as links inside a :COMMON: task, and this will
be the generic Emacs dispatcher I was looking for.


  Thanks

-- Daniel

Re: Re: A simpler remember architecture

[Bernt Hansen]

Daniel Clemente <n142857@gmail.com> writes:

>>
>> To cater more to the OP's needs, consider using a special tag for such
>> common tasks, like :COMMON:
>>
>> The create a special agenda view hat just shows this tag.
>
>
>   This is a very nice solution. I thought of the agenda view as a way
> to view your agenda, but now I see that it can actually serve as a
> generic task dispatcher.
>
>   There are also common files and directories which I often want to
> open. I will write them as links inside a :COMMON: task, and this will
> be the generic Emacs dispatcher I was looking for.

If it's a single link in a headline then you can C-c C-o on the headline
and it immediately visits the link.

HTH,
Bernt

Re: Re: A simpler remember architecture

[Eric S Fraga, Eric S Fraga]

At Tue, 6 Oct 2009 16:33:08 +0200,
Daniel Clemente wrote:
> 
> >
> > To cater more to the OP's needs, consider using a special tag for such
> > common tasks, like :COMMON:
> >
> > The create a special agenda view hat just shows this tag.
> 
> 
>   This is a very nice solution. I thought of the agenda view as a way
> to view your agenda, but now I see that it can actually serve as a
> generic task dispatcher.

Yes, it took me a while of using agenda purely as a list of my tasks
before I realised (thanks to this list) that it was ever so powerful!
I use the tag :clocked: for all my clockable activities (which are not
that many, maybe 8 or so).  

What I found particularly useful was to set the
org-tags-exclude-from-inheritance variable to include :clocked: so
that you can have as complex a hierarchy below any clockable item
without it appearing in the agenda.

eric