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
<address@hidden> 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
<address@hidden> 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.
address@hidden
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
address@hidden
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