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 11:32:39 +0100 Message-ID: <87641glgs8.fsf@bzg.ath.cx> References: <6dbd4d000710080626i52f0f0t9354addc33c0efee@mail.gmail.com> <20071008134353.GA10774@odin.demosthenes.org> <877ilxmimn.fsf@bzg.ath.cx> <20071008202652.GA18426@atlantic.linksys.moosehall> <87k5pxnicj.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 1IfBSH-00079K-Tf for emacs-orgmode@gnu.org; Tue, 09 Oct 2007 05:32:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IfBSF-000780-V0 for emacs-orgmode@gnu.org; Tue, 09 Oct 2007 05:32:45 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IfBSF-00077x-Ow for emacs-orgmode@gnu.org; Tue, 09 Oct 2007 05:32:43 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IfBSF-00059Y-Fn for emacs-orgmode@gnu.org; Tue, 09 Oct 2007 05:32:43 -0400 Received: by ug-out-1314.google.com with SMTP id m4so62017uge for ; Tue, 09 Oct 2007 02:32:42 -0700 (PDT) In-Reply-To: (John Wiegley's message of "Mon, 08 Oct 2007 23:03:39 -0400") 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 John Wiegley writes: > Bastien writes: > >> We could use the TODO keywords instead of "SEND" as a way to say that >> reaching a particular todo state should trigger some kind of action. > > How about just having generalized Lisp triggers: > > :PROPERTIES: > :TRIGGER: (lambda (previous new) > (if (string= (assoc "TODO" new) "DONE") > (org-find-and-schedule "regexp matching task" date))) > :END: > > In this example, previous and new are associative lists containing all of the > state information applicable to an entry. Yes, I like this very much. We could have both a TRIGGER and a BLOCKER property. The first one would trigger actions on tasks. The second one wouldn't let a change appear on the task unless some tasks are in a specific state. I tried to figure out how we could emulate the job of the BLOCKER property with only TRIGGER and an option like `org-check-triggers', saying that the action the TRIGGER is supposed to perform won't be allowed if it's not performed *by the TRIGGER* itself -- therefore enabling us to use "rigid" TRIGGERS and some kind of dependencies checks. But I don't think it's really feasible -- not even a good idea. > This kind of mechanism would allow Carsten to come up with a small > library of org-mode Lisp functions for programmatically manipulating > tasks simply by specifying a regular expression, or a relative offset, > to "locate" them. Yes, sounds like a good idea. > I would far prefer this to a specialized syntax, which in the end would > require so complexity as to become a domain-specific language in itself. I do agree the syntax I proposed was somewhat bloat. Consider it brain-dust after excitment! -- Bastien