From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: Re: depending TODOs, scheduling following TODOs automatically Date: Thu, 11 Oct 2007 13:44:08 +0100 Message-ID: <87ejg1izxj.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 1IfwSa-0005hK-4s for emacs-orgmode@gnu.org; Thu, 11 Oct 2007 07:44:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IfwSZ-0005gb-2B for emacs-orgmode@gnu.org; Thu, 11 Oct 2007 07:44:11 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IfwSY-0005gM-SI for emacs-orgmode@gnu.org; Thu, 11 Oct 2007 07:44:10 -0400 Received: from nz-out-0506.google.com ([64.233.162.239]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IfwSY-00072W-Gz for emacs-orgmode@gnu.org; Thu, 11 Oct 2007 07:44:10 -0400 Received: by nz-out-0506.google.com with SMTP id f1so394787nzc for ; Thu, 11 Oct 2007 04:44:09 -0700 (PDT) In-Reply-To: (Eddward DeVilla's message of "Tue, 9 Oct 2007 10:21:03 -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 (Sorry, I'm writing this in my very-early Eurostar, it may not be accurate at the time it will be sent.) "Eddward DeVilla" writes: > I'm losing track of who proposed what. I was up late last night. I'm > liking the TRIGGER/BLOCKER idea that Bastien has been talking about, Reshaping the proposal for TRIGGER/BLOCKER. Thinking of this again, I believe TRIGGER/BLOCKER should not be properties of a task, but rather of one of their properties. Then look at this: ,---- | * A task | :PROPERTIES: | :TODO: NEXT | :>: DONE (org-todo-in-subtree "DONE") | :END: `---- This says: when the :TODO: property is "DONE" perform the function (org-todo-in-subtree "DONE"), which could be a lambda expression. And then this: ,---- | * A task | :PROPERTIES: | :TODO: MAYBE | :<: NEXT (org-previous-entry-done-p) | :END: `---- This says: only set the property :TODO: to "NEXT" when the previous entry is DONE. The advantage of this implementation is that - it capture John's idea of letting lisp expression do the job of performing actions (and checking for conditions), replacing the hairy ugly syntax I first proposed; - it's property-based, therefore more flexible than :NEXT>: or even :TRIGGER: (unless we use very complex stuff in TRIGGERS) - it looks quite *readable* (especially if indentation is in use) - it's extensible: :>?: trigger action interactively :>!: don't trigger action interactively :>|: don't trigger any action after this one :>>: give priority to this triggered action ... just to give a few ideas. > except it lacks the ability to reference any task that isn't > immediately before, after, under or above the triggering or blocked > task. I'm starting to think links might be to best tool in org for > identifying a task (todo item). I'm not sold on that yet. I may need > to give that another night. I tend to think that a labelling system should not be designed in the same framework than the one we have been thinking about so far to add actions to property changes. After all, labels are only one very specific way to refer to tasks. We can build the trigger/blocker system then make it aware of labels, if any. But more experienced programmers might have better insight on this. Best, -- Bastien