emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Tim O'Callaghan" <timo@dspsrv.com>
To: Carsten Dominik <carsten.dominik@gmail.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 17:55:31 +0200	[thread overview]
Message-ID: <3d6808890909300855v334d8816k6122245d96ecadb0@mail.gmail.com> (raw)
In-Reply-To: <120064D0-FCDF-4B7E-A7D1-933CC9D0F52D@gmail.com>

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

  reply	other threads:[~2009-09-30 15:56 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
2009-09-30 15:55       ` Tim O'Callaghan [this message]
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

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3d6808890909300855v334d8816k6122245d96ecadb0@mail.gmail.com \
    --to=timo@dspsrv.com \
    --cc=carsten.dominik@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).