Re: A much simpler way of handling dependent tasks

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
>