From: Carsten Dominik <carsten.dominik@gmail.com>
To: Tim O'Callaghan <timo@dspsrv.com>
Cc: org-mode <emacs-orgmode@gnu.org>
Subject: Re: A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?)
Date: Wed, 30 Sep 2009 16:50:19 +0200 [thread overview]
Message-ID: <120064D0-FCDF-4B7E-A7D1-933CC9D0F52D@gmail.com> (raw)
In-Reply-To: <3d6808890909300745i4213a0ddo9e12be00c4bb4023@mail.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
>>
next prev parent reply other threads:[~2009-09-30 14:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-29 20:48 A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?) Samuel Wales
2009-09-30 10:39 ` Eric S Fraga, Eric S Fraga
2009-09-30 10:40 ` Carsten Dominik
2009-09-30 14:45 ` Tim O'Callaghan
2009-09-30 14:50 ` Carsten Dominik [this message]
2009-09-30 15:55 ` Tim O'Callaghan
2009-10-01 3:25 ` Sebastian Rose
2009-10-05 23:41 ` A simpler remember architecture Daniel Clemente
2009-10-06 0:24 ` Alan E. Davis
2009-10-01 8:03 ` A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?) Jean-Marie Gaillourdet
2009-10-01 9:14 ` Rainer Stengele
2009-10-01 10:26 ` Peter Frings
2009-10-01 18:41 ` A simpler remember architecture Bernt Hansen
2009-10-02 8:08 ` Jean-Marie Gaillourdet
2009-10-02 13:54 ` Bernt Hansen
2009-10-03 2:48 ` David Bremner
2009-10-06 6:49 ` Daniel Clemente
2009-10-06 11:32 ` Bernt Hansen
2009-10-06 12:27 ` Carsten Dominik
2009-10-06 14:33 ` Daniel Clemente
2009-10-06 14:34 ` Bernt Hansen
2009-10-07 7:17 ` Eric S Fraga, Eric S Fraga
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=120064D0-FCDF-4B7E-A7D1-933CC9D0F52D@gmail.com \
--to=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=timo@dspsrv.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.