From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: A much simpler way of handling dependent tasks Date: Fri, 30 Jan 2009 18:37:09 +0100 Message-ID: <3F4D68F7-625A-472C-9D89-8D6766D61C76@uva.nl> References: <49831696.8030002@diplan.de> Mime-Version: 1.0 (Apple Message framework v930.3) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LSxJp-0004SD-G0 for emacs-orgmode@gnu.org; Fri, 30 Jan 2009 12:38:17 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LSxJo-0004Qf-I7 for emacs-orgmode@gnu.org; Fri, 30 Jan 2009 12:38:16 -0500 Received: from [199.232.76.173] (port=50351 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LSxJo-0004QL-40 for emacs-orgmode@gnu.org; Fri, 30 Jan 2009 12:38:16 -0500 Received: from ey-out-1920.google.com ([74.125.78.144]:17190) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LSxJn-0002Kf-Ig for emacs-orgmode@gnu.org; Fri, 30 Jan 2009 12:38:15 -0500 Received: by ey-out-1920.google.com with SMTP id 4so89742eyg.24 for ; Fri, 30 Jan 2009 09:38:13 -0800 (PST) In-Reply-To: <49831696.8030002@diplan.de> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Rainer Stengele Cc: John Wiegley , emacs-orgmode Org-Mode 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 >