* A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?)
@ 2009-09-29 20:48 Samuel Wales
2009-09-30 10:39 ` Eric S Fraga, Eric S Fraga
2009-09-30 10:40 ` Carsten Dominik
0 siblings, 2 replies; 22+ messages in thread
From: Samuel Wales @ 2009-09-29 20:48 UTC (permalink / raw
To: Carsten Dominik; +Cc: org-mode
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?)
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
1 sibling, 0 replies; 22+ messages in thread
From: Eric S Fraga, Eric S Fraga @ 2009-09-30 10:39 UTC (permalink / raw
To: org-mode
At Tue, 29 Sep 2009 13:48:53 -0700,
Samuel Wales wrote:
>
> Hi Carsten,
>
> Here is an idea for a much simpler remember architecture that
> simultaneously solves Alan's problem.
[...]
> 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.
I like this. Just yesterday, I was in the process of "remembering"
something when somebody came by my office. I talked to the person
and, during the conversation, I had the need to "remember" something
that came up. However, I was already in a remember buffer which was
partially completed. I had to finalise this before I could start a
new remember and this interrupted the discussion I was having with my
colleague.
Your approach would have worked perfectly yesterday!
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?)
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-10-01 8:03 ` A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?) Jean-Marie Gaillourdet
1 sibling, 2 replies; 22+ messages in thread
From: Carsten Dominik @ 2009-09-30 10:40 UTC (permalink / raw
To: Samuel Wales; +Cc: org-mode
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?)
2009-09-30 10:40 ` Carsten Dominik
@ 2009-09-30 14:45 ` Tim O'Callaghan
2009-09-30 14:50 ` Carsten Dominik
2009-10-05 23:41 ` A simpler remember architecture Daniel Clemente
2009-10-01 8:03 ` A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?) Jean-Marie Gaillourdet
1 sibling, 2 replies; 22+ messages in thread
From: Tim O'Callaghan @ 2009-09-30 14:45 UTC (permalink / raw
To: Carsten Dominik; +Cc: org-mode
+1, can we keep/have:
- the templates,
- possibility to 'pick file/topic first then remember'
- 'throw it into the bucket for later'.
- org - remember keymap
- local fontification?
- remove need to have remember package installed?
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
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?)
2009-09-30 14:45 ` Tim O'Callaghan
@ 2009-09-30 14:50 ` Carsten Dominik
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
1 sibling, 2 replies; 22+ messages in thread
From: Carsten Dominik @ 2009-09-30 14:50 UTC (permalink / raw
To: Tim O'Callaghan; +Cc: org-mode
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
>>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?)
2009-09-30 14:50 ` Carsten Dominik
@ 2009-09-30 15:55 ` Tim O'Callaghan
2009-10-01 3:25 ` Sebastian Rose
1 sibling, 0 replies; 22+ messages in thread
From: Tim O'Callaghan @ 2009-09-30 15:55 UTC (permalink / raw
To: Carsten Dominik; +Cc: org-mode
> - '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
>>>
>
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?)
2009-09-30 14:50 ` Carsten Dominik
2009-09-30 15:55 ` Tim O'Callaghan
@ 2009-10-01 3:25 ` Sebastian Rose
1 sibling, 0 replies; 22+ messages in thread
From: Sebastian Rose @ 2009-10-01 3:25 UTC (permalink / raw
To: Carsten Dominik; +Cc: org-mode
Yes, good concept.
> yes
>
>> - possibility to 'pick file/topic first then remember'
>
> No. The idea would be that you refile then or later.
No problem for me. I don't remember a case, when I had to change the
tempalte or target after filling it.
And still, there is `org-remember-goto-last-stored' as well as the
option to always go there after finalizing.
Sebastian
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?)
2009-09-30 10:40 ` Carsten Dominik
2009-09-30 14:45 ` Tim O'Callaghan
@ 2009-10-01 8:03 ` Jean-Marie Gaillourdet
2009-10-01 9:14 ` Rainer Stengele
1 sibling, 1 reply; 22+ messages in thread
From: Jean-Marie Gaillourdet @ 2009-10-01 8:03 UTC (permalink / raw
To: org-mode
Hi,
while we are discussing a new org-remember facility. I've been missing
an option to clock the time I've taken to write down my remember note.
E.g. I use remember to make a small protocoll of a telephone call or
some discussion with a colleague. It would help me alot to if that
time would be clocked automatically.
After the remember note is finalized the previous cloked in task
should become active again. Perhaps with some kind of optional
message/popup/whatever to say: Well, you were doing this before, I
clocked you in again.
It would be even cooler to have a per template flag saying the clock
information should be written into a new headline at some other place.
This would allow to have a log of all remembering actions, that is
separated from the log of the task which were created during
remembering.
I hope this makes sense for someone else as well.
-- Jean-Marie
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?)
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
0 siblings, 2 replies; 22+ messages in thread
From: Rainer Stengele @ 2009-10-01 9:14 UTC (permalink / raw
To: Jean-Marie Gaillourdet; +Cc: org-mode
Jean-Marie Gaillourdet schrieb:
> Hi,
>
> while we are discussing a new org-remember facility. I've been missing
> an option to clock the time I've taken to write down my remember note.
> E.g. I use remember to make a small protocoll of a telephone call or
> some discussion with a colleague. It would help me alot to if that
> time would be clocked automatically.
>
> After the remember note is finalized the previous cloked in task
> should become active again. Perhaps with some kind of optional
> message/popup/whatever to say: Well, you were doing this before, I
> clocked you in again.
>
> It would be even cooler to have a per template flag saying the clock
> information should be written into a new headline at some other place.
> This would allow to have a log of all remembering actions, that is
> separated from the log of the task which were created during
> remembering.
>
> I hope this makes sense for someone else as well.
>
> -- Jean-Marie
>
>
>
> _______________________________________________
> 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
>
Hi,
exactly what I am doing quite often!
Being interrupted (telephone, colleague bringing more work ...) while
working on an clocked in TODO I pop up a remember buffer, manually clock
in, discuss/write down my stuff, save the remember buffer and then have
to find the old task.
Yes, "C-u C-c C-x C-j" shows you the recent clcoked in tasks but
automising the clocking in/out work would make the "remembering" of new
tasks just faster.
Rainer
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?)
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
1 sibling, 0 replies; 22+ messages in thread
From: Peter Frings @ 2009-10-01 10:26 UTC (permalink / raw
To: org-mode Mailinglist
On 01 Oct 2009, at 11:14, Rainer Stengele wrote:
> Jean-Marie Gaillourdet schrieb:
>> Hi,
>> while we are discussing a new org-remember facility. I've been
>> missing
>> an option to clock the time I've taken to write down my remember
>> note.
>> E.g. I use remember to make a small protocoll of a telephone call or
>> some discussion with a colleague. It would help me alot to if that
>> time would be clocked automatically. After the remember note is
>> finalized the previous cloked in task
>> should become active again. Perhaps with some kind of optional
>> message/popup/whatever to say: Well, you were doing this before, I
>> clocked you in again.
>
[snip]
> exactly what I am doing quite often!
> Being interrupted (telephone, colleague bringing more work ...)
> while working on an clocked in TODO I pop up a remember buffer,
> manually clock in, discuss/write down my stuff, save the remember
> buffer and then have to find the old task.
> Yes, "C-u C-c C-x C-j" shows you the recent clcoked in tasks but
> automising the clocking in/out work would make the "remembering" of
> new tasks just faster.
I could image a `clock out and return to the previous one' would be
handy, even out of the remember facility. Nested activities would be
great! Of course, one could always mis-use remember for that (if the
previous feature get implemented, that is), but it feels more
convenient to have nested clocks.
Cheers,
Peter.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: A simpler remember architecture
2009-10-01 9:14 ` Rainer Stengele
2009-10-01 10:26 ` Peter Frings
@ 2009-10-01 18:41 ` Bernt Hansen
2009-10-02 8:08 ` Jean-Marie Gaillourdet
2009-10-06 6:49 ` Daniel Clemente
1 sibling, 2 replies; 22+ messages in thread
From: Bernt Hansen @ 2009-10-01 18:41 UTC (permalink / raw
To: Rainer Stengele; +Cc: org-mode
Rainer Stengele <rainer.stengele@online.de> writes:
> Jean-Marie Gaillourdet schrieb:
>> while we are discussing a new org-remember facility. I've been missing
>> an option to clock the time I've taken to write down my remember note.
>> E.g. I use remember to make a small protocoll of a telephone call or
>> some discussion with a colleague. It would help me alot to if that
>> time would be clocked automatically.
>>
>> After the remember note is finalized the previous cloked in task
>> should become active again. Perhaps with some kind of optional
>> message/popup/whatever to say: Well, you were doing this before, I
>> clocked you in again.
>>
>> It would be even cooler to have a per template flag saying the clock
>> information should be written into a new headline at some other place.
>> This would allow to have a log of all remembering actions, that is
>> separated from the log of the task which were created during
>> remembering.
<snip>
> exactly what I am doing quite often!
> Being interrupted (telephone, colleague bringing more work ...) while
> working on an clocked in TODO I pop up a remember buffer, manually
> clock in, discuss/write down my stuff, save the remember buffer and
> then have to find the old task.
> Yes, "C-u C-c C-x C-j" shows you the recent clcoked in tasks but
> automising the clocking in/out work would make the "remembering" of
> new tasks just faster.
C-u C-c C-x C-i i
Should clock in the interrupted task. Then I use org-clock-goto to get
to it quickly (which is bound to F11 for me)
HTH,
-Bernt
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: A simpler remember architecture
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
1 sibling, 2 replies; 22+ messages in thread
From: Jean-Marie Gaillourdet @ 2009-10-02 8:08 UTC (permalink / raw
To: org-mode
Hi,
At Thu, 01 Oct 2009 14:41:39 -0400,
Bernt Hansen wrote:
> C-u C-c C-x C-i i
Perhaps, it's worth considering shorter and easier to remember
keyboard shortcuts.
> Should clock in the interrupted task. Then I use org-clock-goto to get
> to it quickly (which is bound to F11 for me)
Does this work in the remember buffer or after the remember buffer is
finalized?
Best regards,
Jean-Marie
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: A simpler remember architecture
2009-10-02 8:08 ` Jean-Marie Gaillourdet
@ 2009-10-02 13:54 ` Bernt Hansen
2009-10-03 2:48 ` David Bremner
1 sibling, 0 replies; 22+ messages in thread
From: Bernt Hansen @ 2009-10-02 13:54 UTC (permalink / raw
To: Jean-Marie Gaillourdet; +Cc: org-mode
Jean-Marie Gaillourdet <jmg@gaillourdet.net> writes:
> Hi,
>
> At Thu, 01 Oct 2009 14:41:39 -0400,
> Bernt Hansen wrote:
>> C-u C-c C-x C-i i
>
> Perhaps, it's worth considering shorter and easier to remember
> keyboard shortcuts.
>
>> Should clock in the interrupted task. Then I use org-clock-goto to get
>> to it quickly (which is bound to F11 for me)
>
> Does this work in the remember buffer or after the remember buffer is
> finalized?
Try it. Yes it works fine. Don't forget to save your remember buffer
before you start a new one though.
-Bernt
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: A simpler remember architecture
2009-10-02 8:08 ` Jean-Marie Gaillourdet
2009-10-02 13:54 ` Bernt Hansen
@ 2009-10-03 2:48 ` David Bremner
1 sibling, 0 replies; 22+ messages in thread
From: David Bremner @ 2009-10-03 2:48 UTC (permalink / raw
To: Jean-Marie Gaillourdet; +Cc: org-mode
Jean-Marie Gaillourdet wrote:
>At Thu, 01 Oct 2009 14:41:39 -0400,
>Bernt Hansen wrote:
>> C-u C-c C-x C-i i
>Perhaps, it's worth considering shorter and easier to remember
>keyboard shortcuts.
It is actually not quite as bad is it sounds.
- C-u is the generic "do it differently prefix"
- C-c C-x C-i is the usual start the clock in org. Unfortunately org
has so many commands, that it is probably hard to find a two key
sequence.
At that point a menu pops up, and you choose i.
d
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: A simpler remember architecture
2009-09-30 14:45 ` Tim O'Callaghan
2009-09-30 14:50 ` Carsten Dominik
@ 2009-10-05 23:41 ` Daniel Clemente
2009-10-06 0:24 ` Alan E. Davis
1 sibling, 1 reply; 22+ messages in thread
From: Daniel Clemente @ 2009-10-05 23:41 UTC (permalink / raw
To: Tim O'Callaghan; +Cc: org-mode, Carsten Dominik
Some idea about remember variations:
> +1, can we keep/have:
> - the templates,
> - possibility to 'pick file/topic first then remember'
Actually what I would find useful is a task dispatcher for Emacs: a way to go to common tasks with a few keys.
For instance: C-c C-x C-g would open your customized dispatcher, a dialog similar to C-u C-c C-x C-j (clock recent task) but which shows you predefined tasks, like:
[1] answer phone
[b] breakfast
[p] procrastinate!
[n] think about next task to do
[2] work on file2 a bit more
Each key would bring you to the current buffer and task (e.g.: C-c C-x C-g b would move point to the „*** breakfast“ line in minor_tasks.org.
Clocking would be 1 chord away: C-c C-x C-g b C-c C-x C-i
In fact this dispatcher could be a generic file/task/anything dispatcher for Emacs, which could bring you to any file you wanted in a few keys. Like recentf, but with user-defined positions instead of automatically computed entries.
It could be nice have this inside Org.
-- Daniel
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: A simpler remember architecture
2009-10-05 23:41 ` A simpler remember architecture Daniel Clemente
@ 2009-10-06 0:24 ` Alan E. Davis
0 siblings, 0 replies; 22+ messages in thread
From: Alan E. Davis @ 2009-10-06 0:24 UTC (permalink / raw
To: org-mode; +Cc: Carsten Dominik
[-- Attachment #1.1: Type: text/plain, Size: 2125 bytes --]
I've been watching this thread closely. At this point I want to jump in.
I like the ideas that have been posted here so far, about a different way of
organizing remember in org. I'm not completely certain, but it seems that
part of what was asked for earlier is included in org-remember already, when
the template posts to the file directly, bypassing the remember buffer
altogether. I don't remember why this was unfavorable to me, but in many
ways it is useful. Many of the ideas of the OP and others about the use of
tags, etc., would be more than useful.
Another point, although somewhat off topic, draws my attention:
On Tue, Oct 6, 2009 at 9:41 AM, Daniel Clemente <n142857@gmail.com> wrote:
>
> Actually what I would find useful is a task dispatcher for Emacs: a way to
> go to common tasks with a few keys.
> For instance: C-c C-x C-g would open your customized dispatcher, a dialog
> similar to C-u C-c C-x C-j (clock recent task) but which shows you
> predefined tasks, like:
>
> [1] answer phone
> [b] breakfast
> [p] procrastinate!
> [n] think about next task to do
> [2] work on file2 a bit more
>
>
I agree with this, but I'm not sure how I would want it implemented.
I am currently using a file I have called "general.org" with links to
various projects. Following an idea from Sacha Chua, the following is in
the init file:
:(defun general ()
: (interactive)
: (find-file "~/org/General.org"))
I use it to store links to various projects. It has often occurred to me
how handy it would be if this were integrated better with org-mode. I would
like to be able to start defining a project, with a command that did the
following (at least):
1. interactively ask for a project name and make an org file or
directory (optionally)
2. insert a link either in some list like general.org
3. define (perhaps suggesting a default) key binding
4. perhaps setting up logging or other automatic processes (clocking?)
For now, however, general.org in my setup solves my problem. One more
reason I like having my ~/org hierarchy under git control on three machines.
Alan Davis
[-- Attachment #1.2: Type: text/html, Size: 2652 bytes --]
[-- Attachment #2: Type: text/plain, Size: 204 bytes --]
_______________________________________________
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: A simpler remember architecture
2009-10-01 18:41 ` A simpler remember architecture Bernt Hansen
2009-10-02 8:08 ` Jean-Marie Gaillourdet
@ 2009-10-06 6:49 ` Daniel Clemente
2009-10-06 11:32 ` Bernt Hansen
1 sibling, 1 reply; 22+ messages in thread
From: Daniel Clemente @ 2009-10-06 6:49 UTC (permalink / raw
To: Bernt Hansen; +Cc: Rainer Stengele, org-mode
Just another off-topic but however related...:
> C-u C-c C-x C-i i
>
What if C-u C-c C-x C-i could show, in addition to the recently
clocked tasks, some fixed tasks from a user-defined list?
The dialog would be:
Common tasks:
[1] answer phone
[b] breakfast
[p] procrastinate!
[n] think about next task to do
[2] work on file2 a bit more
Recently clocked in tasks:
[a] working on this
[b] working on that
That list of common tasks could even be progressively created from
statistics of the most commonly clocked tasks.
-- Daniel
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: A simpler remember architecture
2009-10-06 6:49 ` Daniel Clemente
@ 2009-10-06 11:32 ` Bernt Hansen
2009-10-06 12:27 ` Carsten Dominik
0 siblings, 1 reply; 22+ messages in thread
From: Bernt Hansen @ 2009-10-06 11:32 UTC (permalink / raw
To: Daniel Clemente; +Cc: Rainer Stengele, org-mode
Daniel Clemente <n142857@gmail.com> writes:
> Just another off-topic but however related...:
>
>> C-u C-c C-x C-i i
>>
>
> What if C-u C-c C-x C-i could show, in addition to the recently
> clocked tasks, some fixed tasks from a user-defined list?
> The dialog would be:
>
> Common tasks:
> [1] answer phone
> [b] breakfast
> [p] procrastinate!
> [n] think about next task to do
> [2] work on file2 a bit more
> Recently clocked in tasks:
> [a] working on this
> [b] working on that
>
>
> That list of common tasks could even be progressively created from
> statistics of the most commonly clocked tasks.
I just use my STARTED agenda view for this. I have a small number of
tasks in STARTED state for conveniently looking up what to clock in. It
doesn't have a single keystroke access but the list is short enough that
I find it convenient to use.
I don't think we should pollute the recent clock list with other common
tasks. If this is really needed then I think it would be better to be a
separate list so we don't have to share key sequence combinations etc.
-Bernt
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: A simpler remember architecture
2009-10-06 11:32 ` Bernt Hansen
@ 2009-10-06 12:27 ` Carsten Dominik
2009-10-06 14:33 ` Daniel Clemente
0 siblings, 1 reply; 22+ messages in thread
From: Carsten Dominik @ 2009-10-06 12:27 UTC (permalink / raw
To: Bernt Hansen; +Cc: Rainer Stengele, org-mode
On Oct 6, 2009, at 1:32 PM, Bernt Hansen wrote:
> Daniel Clemente <n142857@gmail.com> writes:
>
>> Just another off-topic but however related...:
>>
>>> C-u C-c C-x C-i i
>>>
>>
>> What if C-u C-c C-x C-i could show, in addition to the recently
>> clocked tasks, some fixed tasks from a user-defined list?
>> The dialog would be:
>>
>> Common tasks:
>> [1] answer phone
>> [b] breakfast
>> [p] procrastinate!
>> [n] think about next task to do
>> [2] work on file2 a bit more
>> Recently clocked in tasks:
>> [a] working on this
>> [b] working on that
>>
>>
>> That list of common tasks could even be progressively created from
>> statistics of the most commonly clocked tasks.
>
> I just use my STARTED agenda view for this. I have a small number of
> tasks in STARTED state for conveniently looking up what to clock
> in. It
> doesn't have a single keystroke access but the list is short enough
> that
> I find it convenient to use.
>
> I don't think we should pollute the recent clock list with other
> common
> tasks. If this is really needed then I think it would be better to
> be a
> separate list so we don't have to share key sequence combinations etc.
I agree.
To cater more to the OP's needs, consider using a special tag for such
common tasks, like :COMMON:
The create a special agenda view hat just shows this tag.
- Carsten
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: A simpler remember architecture
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
0 siblings, 2 replies; 22+ messages in thread
From: Daniel Clemente @ 2009-10-06 14:33 UTC (permalink / raw
To: Carsten Dominik; +Cc: Bernt Hansen, Rainer Stengele, org-mode
>
> To cater more to the OP's needs, consider using a special tag for such
> common tasks, like :COMMON:
>
> The create a special agenda view hat just shows this tag.
This is a very nice solution. I thought of the agenda view as a way
to view your agenda, but now I see that it can actually serve as a
generic task dispatcher.
There are also common files and directories which I often want to
open. I will write them as links inside a :COMMON: task, and this will
be the generic Emacs dispatcher I was looking for.
Thanks
-- Daniel
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: A simpler remember architecture
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
1 sibling, 0 replies; 22+ messages in thread
From: Bernt Hansen @ 2009-10-06 14:34 UTC (permalink / raw
To: Daniel Clemente; +Cc: Rainer Stengele, org-mode, Carsten Dominik
Daniel Clemente <n142857@gmail.com> writes:
>>
>> To cater more to the OP's needs, consider using a special tag for such
>> common tasks, like :COMMON:
>>
>> The create a special agenda view hat just shows this tag.
>
>
> This is a very nice solution. I thought of the agenda view as a way
> to view your agenda, but now I see that it can actually serve as a
> generic task dispatcher.
>
> There are also common files and directories which I often want to
> open. I will write them as links inside a :COMMON: task, and this will
> be the generic Emacs dispatcher I was looking for.
If it's a single link in a headline then you can C-c C-o on the headline
and it immediately visits the link.
HTH,
Bernt
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: A simpler remember architecture
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
1 sibling, 0 replies; 22+ messages in thread
From: Eric S Fraga, Eric S Fraga @ 2009-10-07 7:17 UTC (permalink / raw
To: Daniel Clemente; +Cc: org-mode
At Tue, 6 Oct 2009 16:33:08 +0200,
Daniel Clemente wrote:
>
> >
> > To cater more to the OP's needs, consider using a special tag for such
> > common tasks, like :COMMON:
> >
> > The create a special agenda view hat just shows this tag.
>
>
> This is a very nice solution. I thought of the agenda view as a way
> to view your agenda, but now I see that it can actually serve as a
> generic task dispatcher.
Yes, it took me a while of using agenda purely as a list of my tasks
before I realised (thanks to this list) that it was ever so powerful!
I use the tag :clocked: for all my clockable activities (which are not
that many, maybe 8 or so).
What I found particularly useful was to set the
org-tags-exclude-from-inheritance variable to include :clocked: so
that you can have as complex a hierarchy below any clockable item
without it appearing in the agenda.
eric
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2009-10-07 7:17 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
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.