obsidian-tasks: Multi-line tasks (indented lines below a task items) are not shown in Reading mode and Tasks query results

For those who want to still a workaround of having a very descriptive task that needs to span multiple lines, an alternative is to basically hyperlink your task.

...

- [ ] Perform [[this-markdown-page#task_description|task]]

...

...

...

# Tasks/Appendix
## task_description
Have your multiline 
task under this heading
supporting all markdown syntax

Sorry for not responding earlier, Clare! I missed the notification and failed to add a “come back to this” to my tasks tracker. 😅 Work also picked up a bit, so I haven’t had as much “learning time” as before.

That’s definitely a larger chunk of work than I would have hoped for, but I completely agree with the philosophy. I’m out of time for looking at things today, but I will try to make time tomorrow for digging into that some.

One of the benefits of multiple PRs could also be more distributed work, with regards to both time and persons. Hopefully others will be able to build on things as well.

When I say that this is a large body of work, here is the kind of thing that I mean…

tl;dr This isn’t a single-PR change, it’s a series of incremental changes, each of which needs to be safe, and the code on main needs to be releasable throughout the entire process.

If anyone is interested in committing to work on this, I would be available to answer questions, and would add links below to the relevant code locations.

Caveat: this is what I came up with, in about an hour of thinking about it. There may be other things I missed.

Requirements to make this change

My personal philosophy is to always review PRs carefully, to be as confident as I can be that changes (by me and others) do not accidentally cause breakages for users.

This means I only accept PRs to Tasks that contain individual changes, and where any refactorings have been made in small, incremental changes.

I need to either:

• Be able to view the before-and-after code side by side, and reason about all the changes
• Or the PR is made up of small commits, each of which I can review as above

Exceptions to this are:

• There were already extremely thorough unit tests before the refactoring was started

Unfortunately any code in Plugins that imports types from Obsidian like Plugin, MetadataCache, Vault… were not written to be unit-tested… so do not have Jest tests in most plugins.

An exception to this is the Projectswhich may give ideas. (Its licence is Apache - I don’t know if that is compatible with Tasks’ MIT licence.)

How to make this change

I see this change a series of PRs, each of which addresses an incremental part of the project.

For example, there could be some initial PRs to:

• Add thorough test coverage for the areas that will change
• Refactor to unify areas of code where the same thing is done in multiple ways
• Update the storage in Task so that it is capable of reading and writing multi-line tasks
  • But do not expose the feature yet
• Update the rendering so that it does handle multi-line tasks
  • But do not expose the feature yet
• Update the Task toggling code so that it handles multi-line tasks
  • But do not expose the feature yet

etc

How to change the Markdown reading and writing code

It would need to make sure that multiline tasks are both:

• read correctly
• written back out as multiple lines, with the line-breaks in the same places, and the same indentation as before

Storing tasks

• Currently the relevant data in a task is stored like this
  • Would need to look at the code to see where those variables

Task.ts

Searching tasks

• task.originalMarkdown is a documented facility in - Task Properties - so somehow this would need to be maintained, in order to not break user searches
  • At a minimum, that documentation would need to be updated to say how multi-line tasks are represented.

Rendering of tasks

Places to consider:

• Rendering in Reading Mode
• Rendering in Live Preview
• Rendering Search Results (has code in common with Reading Mode)

Users interacting with tasks

• the Edit Task modal…
  • It’s currently designed for the description to be a single line.
  • It’s text box would fit multiple lines already, but how would the user control indentation?
• Toggling tasks
  • See How does Tasks handle status changes?

Testing

• Jest tests would of course be needed
• This is big enough that the Smoke Tests would also need to include a simple test of interacting with a multi line task

User Documentation

• Update Multi-line checklist items

As a case of “two birds with one stone”, would it be possible to consider the following lines of multi-line tasks as part of the description? Then it would be displayed and useable in filters. (I’m willing to contribute to this, if that seems like a reasonable approach.)

@floli I’ve just noticed you’ve pasted the same image link in twice, and it’s not obvious because the image is not shown.

Please kindly edit the report above and paste in the actual images, rather than links to them…

• to ensure that the data is here and not lost in case anything happens to the forum post
• and to save people here from have to click away from this report to understand it.

Many thanks.