From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: depending TODOs, scheduling following TODOs automatically Date: Mon, 08 Oct 2007 21:55:12 +0100 Message-ID: <877ilxmimn.fsf@bzg.ath.cx> References: <6dbd4d000710080626i52f0f0t9354addc33c0efee@mail.gmail.com> <20071008134353.GA10774@odin.demosthenes.org> 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 1IeyhE-0001hk-Sn for emacs-orgmode@gnu.org; Mon, 08 Oct 2007 15:55:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IeyhB-0001cJ-72 for emacs-orgmode@gnu.org; Mon, 08 Oct 2007 15:55:20 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IeyhB-0001bz-1g for emacs-orgmode@gnu.org; Mon, 08 Oct 2007 15:55:17 -0400 Received: from hu-out-0506.google.com ([72.14.214.230]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IeyhA-0000r4-I7 for emacs-orgmode@gnu.org; Mon, 08 Oct 2007 15:55:16 -0400 Received: by hu-out-0506.google.com with SMTP id 23so485819huc for ; Mon, 08 Oct 2007 12:55:15 -0700 (PDT) In-Reply-To: (Eddward DeVilla's message of "Mon, 8 Oct 2007 09:49:08 -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 Implementing tasks-dependencies sounds pretty exciting! I'd like to jump in this discussion with a very simple idea. ,---- | * TODO When this task is marked done, send SCHEDULED to the next task | :PROPERTIES: | :SEND: {SCHEDULED 'next "+1d"} {TODO 'next "TODO"} | :END: | | * When previous task done, this will turn TODO, SCHEDULED for +1 day `---- The basic idea is to *send* a property to a task depending on a state change - in the example above, depending on switching from TODO to DONE. "SEND" would be a special property, composed of repeating curly braced constructs {PROP ADDR VAL}, each of one being composed of: PROP: the property to be sent ADDR: the relative or absolute "address" of the task VAL: the new value for this property (default to the value this property had in the previous task) The "absolute" address could be a GUID or a human readable label. I think this way to send a property (or even to propagate multiple properties to multiple tasks, if needed) would spare us the fuss of implementing real dependencies with real links between the tasks. What do you think? -- Bastien