From: Carsten Dominik <dominik@science.uva.nl>
To: Rainer Stengele <rainer.stengele@diplan.de>
Cc: John Wiegley <johnw@newartisans.com>,
emacs-orgmode Org-Mode <emacs-orgmode@gnu.org>
Subject: Re: A much simpler way of handling dependent tasks
Date: Fri, 30 Jan 2009 18:37:09 +0100 [thread overview]
Message-ID: <3F4D68F7-625A-472C-9D89-8D6766D61C76@uva.nl> (raw)
In-Reply-To: <49831696.8030002@diplan.de>
Hi Rainer,
On Jan 30, 2009, at 4:02 PM, Rainer Stengele wrote:
> John Wiegley schrieb:
>> I've been wanting a simple method for managing dependent tasks for
>> some
>> time now, and only now did it occur to me that I could just
>> implement a
>> much simpler method using your current blocking mechanism.
>>
>> The attached file, confusingly named org-depends.el, implements the
>> following scheme:
>>
>> 1. Any TODO which has incomplete child TODOs is blocked.
>>
>> 2. If a parent TODO has the ORDERED property, it's children must be
>> completed in order. Undone siblings block later siblings.
>>
>> 3. Blocked items are greyed out in the agenda list.
>>
>> John
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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
>
> John Wiegley schrieb:
>> I've been wanting a simple method for managing dependent tasks for
>> some
>> time now, and only now did it occur to me that I could just
>> implement a
>> much simpler method using your current blocking mechanism.
>>
>> The attached file, confusingly named org-depends.el, implements the
>> following scheme:
>>
>> 1. Any TODO which has incomplete child TODOs is blocked.
>>
>> 2. If a parent TODO has the ORDERED property, it's children must be
>> completed in order. Undone siblings block later siblings.
>>
>> 3. Blocked items are greyed out in the agenda list.
>>
>> John
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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
>
> Excellent feature! Thanks a lot!
> Unfortunately most of the times I do use this approach:
>
> * TODO something [0/3]
> - [ ] part 1
> - [ ] part 2
> - [ ] part 3
>
> I would like to get the blocking behavior for the checklist also.
>
> "Any TODO which has incomplete child items is blocked."
Yes, this is an obvious extension, and I was implementing this already.
It is now present in the git repo, dependent on the variable
org-enforce-todo-checkbox-dependencies.
> Even better would additionally be something like:
>
> "Any TODO having at least one item checked is allows the TODO to be
> set to the
> next possible state, for me it would be 'INWORK'."
I think is is too special. You may want to switch such an entry
to INWORK even before the first checkbox can be checked off.
Or you may want to switch to WAITING because you are waiting
for an email that will allow you to check off the first item...
So my feeling is that switching from one not-done state to
another not-done state should not be blocked at all.
In fact, I feel the same for the straight TODO dependencies.
I have now adapted John's mechanism in the following way:
- You are free to change between the different non-done states
- Entries that cannot be switched to DONE will be greyed in
the agenda, but you can still use the agenda to switch them
between not-done states.
- If you call `C-c C-t' (or `t' in the agenda) with a
tripple C-u prefix, any blocking will be circumvented
for the upcoming state change. This is good if you
want to cancel such a tree, before all subitems are done.
I think this is good, and I hope that John agrees.
> Any chance to get at least the blocker feature - the order feature
> would at
> least for me be lower priority?
No plans to make an ORDER feature for checkboxes.
Checkboxes should be light.
Thanks for your input!
- Carsten
>
> Rainer
>
next prev parent reply other threads:[~2009-01-30 17:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-26 21:16 A much simpler way of handling dependent tasks John Wiegley
2009-01-26 23:48 ` Oliver Charles
2009-01-27 1:18 ` Jesse Alama
2009-01-27 6:46 ` Carsten Dominik
2009-01-27 6:47 ` John Wiegley
2009-01-27 6:47 ` Carsten Dominik
2009-01-27 7:31 ` John Wiegley
2009-01-27 7:43 ` Carsten Dominik
2009-01-27 22:51 ` Mike Newman
2009-01-30 15:02 ` Rainer Stengele
2009-01-30 17:37 ` Carsten Dominik [this message]
2009-01-30 20:07 ` John Wiegley
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3F4D68F7-625A-472C-9D89-8D6766D61C76@uva.nl \
--to=dominik@science.uva.nl \
--cc=emacs-orgmode@gnu.org \
--cc=johnw@newartisans.com \
--cc=rainer.stengele@diplan.de \
/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 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.