Re: Re: depending TODOs, scheduling following TODOs automatically

[Bastien <bzg@altern.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" <eddward@gmail.com> 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