New features: Tasks depending on each other and subtasks

[johannesh19]

I'm missing two important features in todo.txt:

• The possibility to signify that one tasks depends on another task being accomplished
• and the possibility to define sub-tasks to an existing task.

However, this requires that tasks are able to reference each other. To do so, I propose the introduction of some key-value-pairs:

• id:[task-id] in the leading task
• dep:[task-id] in the task dependent on another task
• sup:[task-id] for sub-tasks below other tasks.

Since key-value-pairs are already a part of the todo.txt format rules, this feature would be fully backwards-compatible.

This is what an example could look like:

(A) Set up workshop in the @garage id:setupworkshop
(B) Sell jetski sup:setupworkshop
(B) Buy workbench sup:setupworkshop
(C) Repair lawnmower dep:setupworkshop

This describes a task (Setting up the workshop), which has two sub-tasks (Selling the jetski and buying a workbench). Another task, namely repairing the lawnmower, depends on the workshop being set up.

In a UI, sub-tasks could be shown in some sort of tree, while dependent tasks could be greyed out until the first task is done, referring to the blocking task. A rough sketch:

(A) Set up workshop in the @garage
  (B) Sell jetski
  (B) Buy workbench
? Repair lawnmower -> (A) Set up workshop in the @garage

Of course, this could lead to a few logical problems: What to do if there are "short-circuits" or tasks that are not properly nested? Also, can a "top" task be marked as done if "sub" tasks aren't?

# short-circuit
(A) Task 1 id:task1 dep:task2
(B) Task 2 id:task2 dep:task1

# improper structure
(A) Task 1 id:task1 sub:task2
(B) Task 2 id:task2 sub:task1

I'm not yet sure on how to handle these problems. My first idea would be that a sub or dependent task checks if the "top" is still present, and if isn't, ignores the dependency. So (C) Repair lawnmower dep:setupworkshop is handled like (C) Repair lawnmower if the task with the id setupworkshop isn't present in the todo.txt file (or not anymore). As for contradicting definitions, one needs to take priority over the other. This might happen by task priority or other task definitions, or by position in the file/alphabetically/random/…

However, all of this is only a rough idea, and it's quite well possible that I've overlooked some issues. I'd be happy to hear your thoughts on the matter!

[iltempo]

todo.txt is all about simplicity and portability. Simplicity is the beauty that makes task management productive. Instead of managing tasks, time should be spent getting them done.

I can understand your wish for a hierarchic structure of tasks. However, extending a tool opens up many questions that take work to answer. Either implies new rules to the format (≠ simplicity) or builds new logic (≠ portable).

My workflow combines todo.txt with the PARA Method. I keep a separate projects folder containing folders for all bigger endeavors with a definite end. Like setupworkshop in your example. In this folder, I keep all the material needed and a task list in Markdown format. My todo.txt then only contains a task mentioning to pick the next one from the Markdown file or a copy of the next one.