Eddward DeVilla [EMAIL PROTECTED] writes:
I can't say I have any plans to use triggers, but will they really
hurt anything? I mean if it makes the code a mess then that wouldn't
be good. But frankly, I have no need for the GTD 'find a stuck
project' stuff, and it hasn't been a problem for
Rainer Stengele [EMAIL PROTECTED] writes:
I also do not expect to grow Org into anything near a full PM.
But I do would be more than glad to get some basic (trigger or blocker)
functionality to model dependencies between todos.
I would think that setting these up initially would require as
(Sorry, I'm writing this in my very-early Eurostar, it may not be
accurate at the time it will be sent.)
Eddward DeVilla [EMAIL PROTECTED] 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,
Hi,
I am generally against introducing very specialized features to
org-mode, for the same reasons as described by others in this thread.
The power of org-mode lies in simplicify of the model it offers:
information is a collection of lists that can be queried in various
ways.
This model is
Well, I think I'm going to try something else to get the task
dependencies I'm after. I'm using a BLOCKED tag now. I'm thinking
I'll go with a BLOCKED property followed by the list of blockers.
I'll probably use links there, but I'll have to find a way to make
that less fragile with the dynamic
Christian Egli [EMAIL PROTECTED] writes:
To that end my plea is to keep org mode simple. That's why John's
proposal appeals to me. It is flexible and delegates the complexity to
emacs lisp instead of inventing another micro language for dependency
tracking.
Again, I fully agree with that.
On 10/9/07, Christian Egli [EMAIL PROTECTED] wrote:
One of org-mode biggest strengths is its simplicity. I do not want it to turn
into a feature ridden dinosaur that is impossible to maintain.
I was hoping for something more like perl, where the easy things are
easy and the hard things are