Support showing tasks as indented

[wenlzhang]

If tasks are shown as indented, it would be easier to connect them to the context and the corresponding projects.

If the tasks are indented, maybe they can be indented the same as they are in the source file, whether the parent has the tag #task or not and whether the parent is a task or a list item or not. For instance, the following Task A and Task B can be shown as they are.

Tasks of Project A:

- [ ] Task level 1
  - [ ] Task level 2
    - [ ] Task A #task
  - Item level 2
    - [ ] Task B #task

Or maybe this can be an option, and the user can decide whether to show tasks as indented or not in the configuration page.

[schemar]

The issue with this is that one would have to show all parents up to the top level one regardless of whether they are tasks or filtered. Otherwise they would be indented below unrelated tasks in the list above them, which would be confusing. Showing tasks which should be filtered to have the correct hierarchy is also confusing. I have no idea yet how to solve this gracefully. I acknowledge the issue, but it’s not simple.

[wenlzhang]

Indeed, it can be confusing to show the hierarchy if there are several levels of tasks/items. Would it be possible to dim tasks/items that do not have the tag #task then, like what is done when showing the number of tasks?

[schemar]

The more I think about it, the more complex this is 😅

If you have a query for "only open tasks", then how would you render the following?

- [x] #task this is done
  - [ ] #task this is open

[schemar]

It would still exist the other way around. What if I want to show all “done” tasks. What do I show in the following scenario?

- [ ] #task not done
  - [x] #task done

[wenlzhang]

Indeed, this can be tricky to resolve. 😅 How about show it as it is? If the parent is a list item, show it as a list item; if it is an undone task, show it with an unchecked checkbox. This way, the desired result, i.e. undone tasks in this case, can be shown, and the structure can be preserved. Moreover, the fact that there is an undone parent task may also be interesting to know/reflect, although the purpose here is to show undone tasks.

On the other hand, whether the parent is an undone/done task or an ordinary list item, if they are not attached with the tag #task, this means that they are not the main purpose of this query, although they are shown. To make this point clearer, measures like dimming those tasks/items can be used.

[schemar]

True, something like this could work 👍

It would be quite some effort, unfortunately. The current code doesn't track parent/child relationships of tasks/list items. Meaning: to enable this would require an update to most of the code that handles task tracking. I don't think I have the resources to do this right now. Maybe if more people request it.

[chicoary]

I am just starting to use the plugin. In my humble opinion when I use the queries I am only interested in the top pending task. Any other tasks that don't have an expiration date (which is important to see as well) I can see in the note that contains them.

[ghake]

I would also advocate showing the parent items as grayed out/dimmed. Maybe you could use a filter by selecting the following two options for the listing:

• Show Hierarchy of Sub-Tasks as a list.
• Show completed parent tasks in hierarchy as ToDo items

This would fulfill the functionality without confusing the user in the default configuration.

[jroachgit]

I think this would be helpful - would allow easier management of subtasks

[alexisthual]

This feature would be a game-changer to me. I always use nested todo lists and would love to see them in Tasks! 😄
Thanks for the great plugin anyways.

I think you could first start with a rather direct strategy: 1. given the list of filtered tasks, include the context of each task (ie the sequence of all parent tasks) in the form of a task tree (which would actually be a simple list, akin to a path) and 2. then merge these trees so that duplicates don't appear (it might be that a leaf and its parent both get to the first filtered list, but you don't want them to appear twice).

From there, you could add more complex rules (for instance, if a leaf is not done but one of it's parents is done, consider it done), but I think this can come later ☺️

[jamie9090]

+1 !

[therden]

For whatever it may be worth: I prefer Tasks' current presentation of todo items as standalone entities and definitely would not want results to include the context of every item that satisfies their parameters.

If it could be hidden (like the task count) in the query results, then I wouldn't object if Tasks added a short string or emoji to indicate that a task is a "child" of another task. The user could then choose to use the backlink to open that task up "in context" in its source note.

[therden]

What if Tasks used a 'tooltip text' to present a view of the task in the context of a few immediately preceding and following lines in its source note, with indentation intact when the user puts the mouse cursor is over the backlink of a query result?

This would simultaneously eliminate the need for @schemar to make and write complicated code based on assumptions about how notes and lists are structured, avoid 'cluttering' the query results with information that not everyone wants, and make it easy to see the context of a returned task whenever you wish.

[schemar]

Thank you all for the various suggestions. It is currently not feasible to add parsing of task dependencies. Tasks has an extremely simple parser at the moment which only checks each line for whether it is a task. If it is, it parses that line without any additional knowledge about the context except file path and section in the file. A more sophisticated parser is not something I would be able to maintain given my limited time.

However, I am also interested: what do you think about @therden's idea? It would be much easier to store the line number of each task and show surrounding context on hover.

[wenlzhang]

I think @therden 's idea could work, to not complicate things for Tasks.

For managing indented tasks, another option would be to use Dataview, although currently there are some issues with it:

Indented tasks not recognized by Dataview · Issue #459 · blacksmithgu/obsidian-dataview

[st--]

I would love this context-tooltip feature. I've not found that suggested as an actual issue/discussion, so I'll go and create a new issue for it.

[claremacrae]

Super. Thanks so much for supporting Tasks!

[st--]

#2618

[luizcga]

Hi there, nice plugin!
I don't know if it's possible, but why not add an option in the query to just respect the indentation of the current line/task ?
This way if both the parent and child tasks are shown in the query the indentation will be respected.

If the child task comes alone, it will have a strange indentation, but I don't think that's a big problem.
Just don't use the option in the query ...

[luizcga]

Forgot to say I'm a heavy user of nested tasks (sub-tasks) and this feature (with the simple implementation proposed) is essential for the practical use of the plugin for my use case.

[schemar]

The thing is: it wouldn't just look weird. The tasks would be indented under the wrong tasks and look like sub-tasks of those tasks. The sorting algorithm would also need to be aware of sub-tasks, which it isn't at the moment. So right now, the sub-tasks could get sorted above their parent tasks, for example.

[luizcga]

That's true.
These side effects can cause lots of confusion.
Maybe the only way is to be aware of the parent-child relationship of the tasks ... and that will probably demand a big change in the code.

Thanks for the reply, it was worth a try :)

[schemar]

Exactly. Thank you for your understanding.

[claremacrae]

Another request for this: #770

[claremacrae]

There was a related request in #1041

Indented block after a task doesn't get rendered in reading mode

[DeutscheGabanna]

For me it's not even about sub-tasks but sub-lists that give context. Like so:

[subsector]

Yes, this is exactly what I'd like to see. You can get that indented note context using dataview queries instead of the plugin query notation though.

[subsector]

This returns all tasks, grouped by location, excluding one directory, displaying indented sub-text.

dv.taskList(dv.pages('-"Extras"').file.tasks
.where(t => !t.completed &&
!t.text.includes("#task")
))

[claremacrae]

Are you sure about that?

I've been trying to raise awareness of the difference between t.completed and t. fullyCompleted in dataview.

I think lots of people miss out on important tasks in dataview because the docs focus on completed and not fullyCompleted.

https://blacksmithgu.github.io/obsidian-dataview/data-annotation/#implicit-fields_1

fullyCompleted: Whether or not this task and all of its subtasks are completed.

[subsector]

Ah, I wasn't aware of that. I've also realised that the dataview approach won't really work for completing recurring tasks.

[claremacrae]

Just to set people's expectations on this - implementing this will be a major, major piece of work in Tasks.

I'm not saying it won't ever be done.

But it won't be done any time soon, as there are so many other feature requests and bug fixes that can be done without rewriting the innards of this plugin.

(I do understand the value of it. So there's no need for more comments along those lines, thanks.)

[jrobiii]

I don't use it that often, but my workaround is to prefix the subtasks with <br>. E.g. - [ ] Backup Pruning <br>- [ ] Asdf Job <br>- [ ] JkLm script <br>[waiting::for completion of [[2022-08-30 - Meeting Xyz#^85164c]]]
Renders like so:

• It's not pretty
• Gets more ugly with deeper levels of subtasks
• Have to got to origin note to check subtasks
• Queries don't take into account subtask completion
• Too many more to list

But it works for my workflow when I need subtasks 😃

[claremacrae]

Very many thanks for sharing this!

[TriplEight]

I'm also using this approach as the only way to view the tasks with details. And yes, it's ugly.
And it does not allow any sub-items to be #tasks. Which is fine: usually those are checklists, thus synchronous. Also, it's fine since they are observable. While another, asynchronous task starts anew.

Suggestion: treat any sub-items (without <br>) as a task description. Ignore if they are tasks and include in the filters/search results by default. This will at least improve readability.

[claremacrae]

Suggestion: treat any sub-items (without <br>) as a task description. Ignore if they are tasks and include in the filters/search results by default. This will at least improve readability.

@TriplEight I'm struggling to understand this suggestion. Please start a new Feature Request, describing your suggestion with concrete examples, and linking back to this?

[claremacrae]

#1634 gives a very nice explanation of how handling of nested tasks might work.

I have created a new label - scope: sub-tasks and super-tasks - for related tasks.

[cyChop]

This feature would be really, really nice, but I understand the complication + Tasks already have many users, that are used to the current behavior. I think showing the nested tasks (or lists for context) should be new options: old task lists would not be changed, but new query options would allow to specify that sub tasks are wished for.

#1634 is indeed a way to do it. However, I'd suggest adding a "show task tree" query (name it better, I'm lacking imagination). The "not done" query should only apply to leaves (or nodes with only done sub nodes), so that the context of a not-done task is never lost, and indented tasks always show under their parent.

I understand having a "not done" query that would still show done nodes can be confusing, but that's the simplest way I can think of not to lose the context. With a clear documentation (Kudos on that work, too, by the way!), I think it should be fine. Using something like "task tree" rather than "subtasks" in the query could also help: you can browse a tree in both directions, from roots to leaves and the other way around. Showing the whole tree implies that the whole hierarchy should be preserved.

Another query might be to show not only subtasks, but also sublists. I'd keep it a separate query, even though I suppose the code used in both cases would be quite similar (but I might be wrong on that one: for subtasks, you filter on leaves' status; for sublists, the leaves have no status).

Another option (but I think it should be a user preference) would be to finish all subtasks when you finish a parent task. It makes sense from a logical point of view: when you cut a branch, it dies. Still, everyone works in a different manner with tasks and I don't think it would be a good idea to make it the default behavior.

[claremacrae]

Thank you for a very helpful and considerate message!

[reagle]

In terms of seeing what nested tasks look like, you might look at how Zim wiki does this.

[claremacrae]

To save others looking, here it is:
https://zim-wiki.org/

I'm not seeing the link to this topic though. Can you be any more specific please @reagle ?

[reagle]

Sorry, that was a rushed comment. I'd like to move to Obsidian from Zim (I prefer markdown files to its format; nicer table editor; mobile clients) but I am dependent on its task manager which supports nesting and inherited tags and priorities. (I also like using simple text specification to icons for priorities and dates.) I was looking at Obsidian issues to see if these are likely and thought to recommend the way Zim presents completed parent items.

• Even though "create a task list" is completed:
  • Priority is indicated by "!!" and you can see its children have inherited from the completed parent; if you clicked the @test tag, you'd see that is inherited by children too.
  • It's still shown in the task viewer because it has children. (It could be a different/gray color though.) The completed item, with no children, is not shown.

[claremacrae]

Thanks very much for the reply, and the very clear description.

I cannot see the Tasks plugin supporting this workflow any time soon - there is a lot of foundational work to be done before we get anywhere near what you describe.

The dataview plugin is probably your best bet. Make sure you check out its completed and fullyCompleted features., and know the difference.

Other than simplicity of searches, the main thing Tasks offers over dataview is support for recurring tasks... so if you don't use them, dataview would likely be fine.

[reagle]

Thank you, I hadn’t considered looking at dataview.

[AndriiPetrovDev]

I have trouble even with a really simple case. I love the Tasks plugin, but I need indentation.
Obsidian 1.3.5
Tasks 4.1.0

[AndriiPetrovDev]

Dataview is great but lacks some cool features like editing task from the modal window with custom statuses

[AndriiPetrovDev]

Ok, if the Tasks doesn't support nesting tasks, could you please suggest a simple replacement approach?

[claremacrae]

Just to be clear, it does support reading nested tasks.

I have already suggested a replacement approach: dataview.

[AndriiPetrovDev]

Oh, just reading, without rendering. Now it's clear, thank you. I prefer to use Tasks instead Dataview. Just need to use something instead of nesting

[claremacrae]

Oh, just reading, without rendering. Now it's clear, thank you.

Glad to hear it. Here is how that shows up in your screenshot from above:

[srfrew]

Hello! I'm in a similar place, where indented task lists are essential for organization by project or subtasks. If there could be a query to preserve this structure, that would be phenomenal.

[claremacrae]

@srfrew Im afraid your best bet is probably to switch to the Dataview plugin the
N, and use its ‘fullycompleted’ search option.

[vikhik]

Thankfully, looks like work on this has started:

#1634 (comment)

[claremacrae]

I'm delighted to announce that this is now supported in Tasks 7.12.0.

See the documentation to find out how it works, and how to enable it either in individual queries... or if you wish, add it to your Global Query to turn it on by default.

This rendering step is the first in a series of steps to fully support nested tasks in Tasks - it is already really very useful.