Ihor Radchenko <yanta...@gmail.com> writes:

>> Everyone has their own workflows, but I think the way you are approaching
>> this problem is "wrong". 
> I think I need to elaborate on the use-cases more then.
> I am well aware about the concept of NEXT actions, GTD, projects, and
> using categories to bring task context in agenda. However, the problem I
> am trying to solve is more subtle.
> Sometimes, subdividing a task into NEXT sub-tasks is simply overkill
> leading to redundancy. Consider the following example of reading a book,
> when the task of reading is also part of bigger project:

Chiming in briefly to say that I agree: many of my TODO use-cases simply
don't make any sense broken up into sub-tasks. So much of what I do is
email-based discussions -- about project proposals, textual edits,
contract negotiations -- and as the discussion evolves the TODO bounces
back and forth between NEXT and WAIT. This is also the fundamental
approach of Gnorb. There's no useful way to break that evolving
discussion into subtasks. All I want to know is, what am I WAITing on
and how long have I been WAITing, and if the ball's in my court, what am
I doing NEXT.

I looked into implementing something like what Ihor is suggesting
(except using a message-area echo), ran into some of the same
difficulties (the semi-real status of notes), and then noticed that
<SPC> on an Agenda item shows the item in another window with its
LOGBOOK expanded, meaning you can see the whole evolution of the TODO at
a glance. And "o" hides it away again. That took most of the steam out
of my plans, and I figured it was good enough.

Re the formatting issue, maybe the easiest thing would simply be to say
by fiat that only notes in a LOGBOOK drawer were eligible for special
parsing. If you're sticking notes in the subtree body, they're just a
list. Since no special note-handling facilities currently exist, no one
would lose out on anything if we said any future such facilities would
require the LOGBOOK.


Reply via email to