[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Orgmode] Re: Question about tracking TODO state changes and M-S-ENTER

From: Keith Swartz
Subject: [Orgmode] Re: Question about tracking TODO state changes and M-S-ENTER
Date: Wed, 27 May 2009 15:48:19 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070326 Thunderbird/ Mnenhy/

I agree -- now you have choice instead of inconsistency. I like it. I mean, as a user, I like it. If I had to maintain this code, I'd hate it. So I'm glad it's you and not me. Kudos. :D But seriously, thanks for the discussion.

Although if the variable name really is ...-seletion-... and not ...-selection-... then I'd have to go back to saying it's a bug. :)


PS: Whoops, I see Bernt already caught that! Man, you people are fast.

Carsten Dominik wrote:

On May 27, 2009, at 10:04 PM, Keith Swartz wrote:

Actually, that's a good idea. I just went and modified my remember template to emulate the logbook behavior, so now I can use that consistently. Should have thought of that.

But we still have an inconsistency here. There seems to be a rather widespread agreement that creating a TODO item shouldn't register a state change. If there's no objection to that (and there isn't from me), then changing a regular bullet to the "TODO" state for the first time shouldn't either. So I think that's kind of a bug.

I am, actually, going the other way here.  I do very much like to have
state notes when I am really working on stuff. But setting up state notes has the annoying side-effect that I am also prompted for notes when I really
want to flip through to some initial state, without taking notes.

Therefore, just so that you hate it more (:-) I have also introduced yet another variable `org-treat-S-cursor-todo-seletion-as-state-change', and I will set it (personally) to nil. Then I can use S-right to flip through states without taking notes, and C-c C-t to switch to a state with taking a note.

I call this not inconsistency or a bug, I'd call it choice :-)

- Carsten

I don't think it's worth having a variable to turn it on/off, imho, since there are other ways to achieve this, but if we want to preserve that functionality for backwards compatibility for a few releases, I'd think it's not much work to add one.

Thanks for the great ideas.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]