emacs-orgmode
[Top][All Lists]
Advanced

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

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


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

On 10/9/07, Christian Egli <address@hidden> 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 possible.  My hope for any feature in org
is that if you don't need it, it doesn't affect you and you don't need
to know it exists.

> I keep my projects simple. I plan not for the sake of planning but to get an
> overview. So for dependency tracking I usually just reorder my tasks. I don't
> want to fidget with my plan all day. I want to get things done :-)

Same here.  I'm just now in a position where I need to make sure I get
them done on time and it's starting to require some creative planning.
 A planning mistake now could really hose me 9 months from now.
Tracking complex dependency relations between tasks would go a long
way in help me see avoid such mistakes.  Obviously, not everyone is in
that boat.  I wasn't a few months ago.

> 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.

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,
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.

If we go that route, I think I'd like to see a common library of code
come with org to keep us from reinvent wheels and so we can have a
subset of 'trusted' code.  (I'm security minded.  I'd hate to reinvent
the mistake of embedded VB script in documents.)

Edd




reply via email to

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