From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: depending TODOs, scheduling following TODOs automatically Date: Tue, 09 Oct 2007 03:42:35 +0100 Message-ID: <877ilxnh44.fsf@bzg.ath.cx> References: <6dbd4d000710080626i52f0f0t9354addc33c0efee@mail.gmail.com> <20071008134353.GA10774@odin.demosthenes.org> <877ilxmimn.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1If47O-0000JE-FE for emacs-orgmode@gnu.org; Mon, 08 Oct 2007 21:42:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1If47M-0000Ip-4D for emacs-orgmode@gnu.org; Mon, 08 Oct 2007 21:42:41 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1If47L-0000Im-Tq for emacs-orgmode@gnu.org; Mon, 08 Oct 2007 21:42:39 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1If47M-0004dd-Gk for emacs-orgmode@gnu.org; Mon, 08 Oct 2007 21:42:40 -0400 Received: by ug-out-1314.google.com with SMTP id m4so28854uge for ; Mon, 08 Oct 2007 18:42:36 -0700 (PDT) In-Reply-To: (Eddward DeVilla's message of "Mon, 8 Oct 2007 15:35:22 -0500") 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: emacs-orgmode@gnu.org "Eddward DeVilla" writes: > My only real issue is that I tend to think of task dependencies in > terms of the other tasks a given task is waiting on rather than what > other tasks are waiting on a given task. Ok, then: * Task A * Task B :PROPERTIES: :>TODO: {TODO 'previous "DONE"} :END: => becomes TODO when previous tasks is DONE. > This feels a little backward to me, but I could still use it. I'd > still have to think about how to use this to make projections, but all > the info is there for that. Sure! Two ideas again: 1) one aspect of Org is that it is very *fast*; we can change the TODO state of an item with just one keystroke. Making this change trigger actions should require some kind of double-check, otherwise we could end up with a lot of changes that we're not fully aware of. One way to check the triggered changes is to build an actions pool gathering all actions to be performed, then ask the user if he wants to perform them. 2) In my proposal, the actions are just triggered by TODO state changes. But each action could affect or be affected by any property. * Task A :PROPERTIES: :COLOR: red :END: * Task B :PROPERTIES: :>TODO: {COLOR 'previous "green"} :END: => becomes TODO when previous tasks property COLOR is "green". ... -- Bastien