Add nesteds tasks

[pistacchio]

It would be helpful to be able to indent-dedent tasks to create nested tasks (sub-tasks of taks).

[irrationalistic]

This is an interesting idea, though could be pretty complex! Can you elaborate on how it might work? Like what the expected behavior might be? You can certainly indent tasks now, but they have no relationship with the parent task.

[eboracus]

I just came by to suggest something similar. I think that maybe introducing a new distinct command eg. 'parent-task' for this would be useful?

This could set up a task with its own marker that then 'observes' the state of each task that is directly beneath and with a greater indentation than the parent task. Terminating the list by a blank line(?) automatically, or by applying a secondary tag with another command given on another selected line manually (though that sounds more cumbersome/messy :/ )?

The parent task could have a tag appended to it (a la @done/@ cancelled), something like @status(2/6) to show the number of completed sub-tasks, updated on the action of resolving (completing/cancelling) any sub-task. When all sub-tasks are completed the parent marker updates to show green tick (all sub-tasks completed), red cross (all sub-tasks cancelled) or a new third type of marker green tick with a small red cross subscript (majority sub-tasks completed) or red cross with small green tick subscript (majority sub-tasks cancelled).

Archiving removes a sub-task from the check and @status could go to (2/5, 1 archived), and cancelling could go to (2/5, 1 cancelled)? Parent tasks could be 1 ordinary sub-task of a higher (grand)parent task that uses just the same command.

...or something else entirely :p Certainly not thought of every possibility and not a perfect approach, but figured that sounds more doable than more full automation.

edit: oops accidentally @mentioned someone with the @'s

[irrationalistic]

Thanks for weighing in on this, @eboracus! Right now, nested projects are supported, which comes a bit closer to the goal here too, just a thought.

I think the behavior you describe makes sense. The @status tag could be updated whenever children are updated, but it would get weird when you have more than two levels nested, right? Like, if you have something like:

task a
  task b
  task c
    task d
    task e

What happens when you complete or cancel task c? When you complete task e and task c receives an @status(1/2), what status would task a get? If you complete both task d and task e, would task c automatically be considered completed as well? I think the answers to these questions are definitely solvable, just need to make sure that the behaviors are expected. That's why i'm asking so many questions :) There could definitely be a new icon for "parent" tasks that's like a little right-pointing arrow to show it's not a project but also doesn't act like a normal task. It could allow special behavior on those types of tasks that, if you hit "complete" on a parent task, it automatically sets the complete flag on all the children of that task, thus "completing" the parent task too.

I guess i'm not so worried about the archiving process because you can keep all the tags as they are and just stack everything as normal. Maybe it keeps the indentation hierarchy, but i don't know if that's super important.

[eboracus]

I've not used projects is that covered in the readme, I didn't see any reference.

Yes above I was admittedly, in the interests of more straight forward and faster implementation, just leaving things as: C only gets completion when D & E are completed and has no separate manual completion toggle of its own. And additionally C (or D && E together) counted as simply 1 item in A's status list.

I can definitely see having a separate manual toggle being pretty desirable too, maybe have it so issuing the command once creates an auto-completing parent task, issuing the same command again on that task creates a 'toggle-able completion' parent task. Or just the same create task command as exists now with multiple values(?) Not sure whether two commands (one with two values) or 1 with three possible values would be better.

But for separately toggle-able parent tasks how about something like:

• [ ] Task 1 @status(3/3, primary[0/1])
  • [x] Sub-task 1.1 @done()
  • [x] Sub-task 1.2 @done()
  • [x] Sub-task 1.3 @done()

where an arrow icon could turn to the subscript green tick version when all sub-tasks are done, but not the primary.

And for nested tasks:

• [ ] Task 2 @status(2/5, 1 sub-task[1/2])
  • [x] Sub-task 2.1 @done()
  • [ ] Sub-task 2.2
    • [ ] Sub-sub-task 2.2.1
    • [x] Sub-sub-task 2.2.2 @done()
  • [x] Sub-task 2.3 @done()
    • [x] Sub-sub-task 2.3.1 @done()
  • [ ] Sub-task 2.4
  • [ ] Sub-task 2.5

possibly a more concise labelling than 'sub-task' in the brackets though :confused: And maybe, for more complex nesting, just stating how many sub-tasks are 1 away from completion, how many are 2 away etc... (and how many are 0 away with only the primary task uncompleted). Hopefully that would stop the status from becoming too difficult to read at a glance. :/ Having two separate versions of the parent task I think should mean that, if you've chosen manual, if 221 and 222 are both completed and 2.2 isn't manually toggled then it shouldn't count towards the main count.

Is something like this implementable in the current setup?

[irrationalistic]

Projects (or headers in the readme) are created by adding a : to the end of a line:

Header 1:
  ☐ First task under header

When completing or cancelling a task under a header, it automatically gets added as a tag for reference when archiving :)

Thank you for giving this so much thought! I imagine a first iteration could be pretty straightforward:

• A parent task is any task item that has child task items nested within.
• A parent task item cannot be manually completed or cancelled.
• A parent task item will only be changed to completed if all tasks within have also been completed or cancelled, as long as at least one item was completed.
• A parent task item will only be changed to cancelled if all tasks within have all been cancelled and none completed.
• If all child tasks are completed and the state of the parent item has been set to completed and the user then un-completes the child task, the parent task will also be un-completed.
• As children tasks are completed or cancelled, a running count in a tag on the parent item will be kept, looking only at first-level children and not grandchildren.

Some example views:

> Task 1 @status(1/3)
  ☐ Task 1.1
  > Task 1.2 @status(1/2)
    ☐ Task 1.2.1
    ✔ Task 1.2.2 @done()
  ✔ Task 1.3 @done()

✔ Task 1 @done()
  ✔ Task 1.1 @done()
  ✔ Task 1.2 @done()
  ✘ Task 1.3 @cancelled()

✘ Task 1 @cancelled()
  ✘ Task 1.1 @cancelled()
  ✘ Task 1.2 @cancelled()
  ✘ Task 1.3 @cancelled()

This should be doable within the current setup. I'm not as comfortable with toggling manual/automatic states on tasks as that may bloat the tag architecture. How do these initial rules and examples sound to you? Can you see any odd cases where they would break down?

[eboracus]

Yes, that looks pretty reasonable to me, I don't see any major issues.

That's good that the creation of a task group can be automated (so no manual initial setup), wasn't sure if things under the hood were conducive to that without overhauling... nice. :+1:

An option of a toggle on the main task would still be 'nice', for example:

Understand issue X

• Read text 1
• Read text 2
• Ask person Y

Reading the second text/asking someone wouldn't necessarily immediately complete the understanding and, in this case at least, adding an "Understood" as a 4th sub-task wouldn't be the most elegant way of completing things, given its repeating the opening main task.

Certainly a pretty minor issue though so its no problem if it can't be brought in in a simple way, just worth noting I think.

[cs-1]

I just swung by the issues page to simply ask if it'd be possible to immediately indent a task after using Cmd-Enter by hitting Tab (without moving the cursor in front of the checkbox first). However, this is even cooler. :) @irrationalistic I really like your suggestion in your last post. My team and I use the tasks package extensively in Atom and we'd really appreciate this enhancement because we often have to deal with nested tasks. Thanks for the excellent work you put into this package, it's a great tool for our daily work. :)

[irrationalistic]

Thanks, @cs-1! Glad this is helping you out :)

I haven't had a lot of time to work on this and i think there are still some edge cases to work out. Any help would be appreciated if anyone wants to submit a pull request ;)