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

[Carsten Dominik <carsten.dominik@gmail.com>]

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