emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] depending TODOs, scheduling following TODOs automatically


From: Eddward DeVilla
Subject: Re: [Orgmode] depending TODOs, scheduling following TODOs automatically
Date: Tue, 9 Oct 2007 09:53:21 -0500

On 10/9/07, Bastien <address@hidden> wrote:
> "Eddward DeVilla" <address@hidden> writes:
> > It's more like, work can't even begin E until A, C & D are done.  Work
> > can't start F until A & B are done.
>
> Would the TRIGGER/BLOCKER be okay for that (assuming we can use John's
> proposal of using lisp expressions and a set of predefined actions)?

I think so.  It kinda clicked for me in the other thread.  I'd
probably use BLOCKER more myself, but I think I like the idea of using
it with TRIGGER to have a high level task that is marked done or would
depending on it's sub tasks.  It would be like a todo item equivalent
to the [/] & [%] tokens in plain lists.

> > Again, interesting, but different from where I was going.  I'm not
> > after editing as a side effect.  Just planning and organizing.  In a
> > previous message you said it isn't as complex as package dependencies.
> > I guess what I was after might be.
>
> Yes. I thought allowing side effects (forward) and checks (backward)
> would be enough - for the sake of keeping implementation simple.

That part of it is seems pretty simple and elegant.

> Maybe this was just an over-reaction to the idea of GUID or labels,
> which sounds like we are going into trouble.

GUIDs did sound a little off for org.  Labels would introduce a
management /maintenance problem for the user.  I felt I needed
something to built my dependency relations with.  It's hard to
'address' a todo item.  Link's might be the best thing we have for
that.

For me, linear ordering would not be enough and requiring the
hierarchy to model the dependencies will require me to break up tasks
that logically belong together.  It just might be that it's not time
to address that though.

Edd.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]