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

[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