emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Carsten Dominik <dominik@science.uva.nl>
To: Rick Moynihan <rick@calicojack.co.uk>
Cc: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: Undoing from Org Done Notes
Date: Fri, 5 Sep 2008 12:06:31 +0200	[thread overview]
Message-ID: <F74184D4-361D-47A7-BC4E-A8FC3C3B063C@uva.nl> (raw)
In-Reply-To: <48C1008C.6000403@calicojack.co.uk>


On Sep 5, 2008, at 11:49 AM, Rick Moynihan wrote:

> Hi Carsten,
>
> I'll give Bernt's suggestion a try, and hopefully this will happen a  
> lot less.  I am quite fond of the sequence shifting keys though, so  
> we'll see how I get on.
>
> Rather than re-defining undo, which I can see might cause problems.  
> Would it be possible to add an extra command into that buffer  
> (perhaps on C-c u) that was essentially a keyboard macro for this  
> simple sequence?
>
> C-c C-k
> C-_
>
> I've just tried a defining a macro for this, and it appears to work.  
> Would having the following display be a good idea?
>
> # Insert note for closed todo item.
> # Finish with C-c C-c, cancel with C-c C-k, or restore the todo item
> # to it's previous state with C-c u.
>
> Thinking about this now, is there ever a time when you want to C-c C- 
> k and not undo the state change??  For me, this would seem to be a  
> better behaviour, but then I'm probably missing something.

Hi Rick,

this is a good proposal.  However, the way the note-recording process  
is implemented (using a post-command-hok) makes me worry that after  
finishing the note it may not be guarantied to be returned to the  
correct buffer, in which case the undo might have undesired results.   
Also, the note taking mechanism is not only used after state changes,  
but can also be triggered by a clocking event, or by a command from  
the agenda.  In these cases, the undo would definitely be unwanted,  
while you still want to be able to abort the note.

Also, I believe that C-c C-k is useful as it is, because it aborts  
inserting the note but leaves the new state.  I use it when I have  
switched the state correctly into a state the request a note, but I do  
not want to record a note.

So I guess you are stuck with writing your own little function... :-)

- Carsten

>
>
> Thanks again for your tireless work,
>
> R.
>
> Carsten Dominik wrote:
>> Hi Rick,
>> since you are normally going to edit the note, certainly with the   
>> ability
>> to undo, I don't think it makes sense to redefine undo for this.   
>> I  can see how what you
>> ask for would be useful, but I see no good logic to implement it.
>> Maybe the easiest is to define yourself a separate key for  
>> switching  sequences,
>> so that it is less likely to press S-right by accident?
>> - Carsten
>> On Aug 12, 2008, at 1:38 PM, Rick Moynihan wrote:
>>> Hi all,
>>>
>>> I make quite extensive use of org's sequences, and make use of  
>>> the  org-log-done features to prompt for a note when a task is  
>>> closed.
>>>
>>> My problem is that when reorganising I often push a sequence on to  
>>> a  done state instead of switching sequences, i.e. I press S- 
>>> <Right>  instead of C-S-<Right>.  When this happens a note window  
>>> is popped  up, where by I am forced to press C-c C-k to close the  
>>> note window,  then I need to press C-S-_ to undo the original  
>>> change.
>>>
>>> One thing I have noticed is that my reflex action upon seeing the   
>>> Note and realising that's not what I want, is to press undo at  
>>> that  point. Rather than enter the mildly frustrating workflow  
>>> above,  would it be possible to have undo close the note, and then  
>>> revert  the headline into it's previous state, by calling undo  
>>> again in the  original buffer?
>>>
>>> Obviously you'd only want this if the Org Note buffer didn't  
>>> contain  any changes.  If it did, the stock undo behaviour makes  
>>> sense,  except when you've made some changes and spent all your  
>>> undo's,  pressing undo again might want to ask whether you want to  
>>> close the  note and revert the state change in the previous buffer.
>>>
>>> Does this make sense?
>>>
>>> R.
>>>
>>>
>>> _______________________________________________
>>> 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:[~2008-09-05 10:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-12 11:38 Undoing from Org Done Notes Rick Moynihan
2008-09-02 17:20 ` Rick Moynihan
2008-09-02 19:21   ` Bernt Hansen
2008-09-05  5:42 ` Carsten Dominik
2008-09-05  9:49   ` Rick Moynihan
2008-09-05 10:06     ` Carsten Dominik [this message]
2008-09-05 14:10       ` Rick Moynihan

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=F74184D4-361D-47A7-BC4E-A8FC3C3B063C@uva.nl \
    --to=dominik@science.uva.nl \
    --cc=emacs-orgmode@gnu.org \
    --cc=rick@calicojack.co.uk \
    /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).