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

[Samuel Wales <samologist@gmail.com>]

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