emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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
>

  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

  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=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 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).