Give a visual indication in Tasks Results blocks (initially - maybe Reading view later) to show if there are indented simple list items or checkbox items that Tasks has hidden

[ilandikov]

⚠️ Please check that this feature request hasn't been suggested before.

• [X] I searched previous Ideas in Discussions didn't find any similar feature requests.
• [X] I searched previous Issues didn't find any similar feature requests.
• [X] I am only requesting a single feature. Multiple changes should be split into individual requests, with links between them.
• [X] I believe my requested feature will be generally applicable to other users, not just me: it is not uniquely tied to my personal workflow.

🔖 Feature description

Sometimes I have notes under the task, for example:

- [ ] #task pack the bag for a gig
  - mac
  - charger
  - controller
  - USB cable
  - etc

or

- [ ] #task pack the bag for a gig
  - keep weather in mind since if it's snowing or rainy I may need another bag to keep the gear safe

Why not integrating the notes in the task line? 1/ these are just dummy examples, sometimes notes can be pretty long and 2/ I like to keep the tasks short so that the query output is not polluted with too much info.

✔️ Solution

I'd like to see in the query output an indication that the task has some notes inside it. Just a simple emoji or something like that. So the output shall be like

- [ ] #task without notes
- [ ] #task with notes *

where the * is the indicator, it shall be something else obviously =)

❓ Alternatives

Dunno, mark manually the tasks body like - [ ] prepare the bag (check notes) =)

📝 Additional Context

No response

[claremacrae]

Hi @ilandikov, thanks for the suggestion.

Add 'notes' mark/emoji

Please could you clarify that title - add them to do what and why? It currently can be read that this is asking for users to have to add a new emoji in their markdown files in order for sub-list items to be displayed... (because that is where emoji have been used in Tasks so far...)

The fact that Tasks drops nested non-task lines, and does not indent nested tasks, has been reported many times.

This is, I think, the highest voted request:

• https://github.com/obsidian-tasks-group/obsidian-tasks/discussions/60

Why not integrating the notes in the task line?

Because Tasks was not designed to. I have labelled requests that require changes to the core Tasks code with the label scope: requires core redesign - including this one. So you can search and see related discussions, if you are so inclined...

I'd like to see in the query output an indication that the task has some notes inside it. Just a simple emoji or something like that...

Knowing that there is a nested bullet point (or task) is likely a significant part of the work of this request.

It feels to me like the better fix for the missing list items is to actually display them... It's what dataview does - and it's a serious issue that Tasks hides them (both in Reading view and in Query results view)

[ilandikov]

Please could you clarify that title - add them to do what and why?

Ah right, thanks. So if I have this task:

- [ ] #task pack the bag for a gig
  - mac
  - charger
  - controller
  - USB cable
  - etc

it will show up in the query as:

- [ ] #task pack the bag for a gig

And from this perspective I have no way to know that there are some notes under the task. And I would like to =) that's the "why" =)

The fact that Tasks drops nested non-task lines, and does not indent nested tasks, has been reported many times.

I'm aware of that and this request is not about nested tasks. This is just to show in the query that there is something "under" the task without showing what it is. That's all =)

[claremacrae]

Sorry I was unclear. I was asking if it would be possible for you to edit the Summary of this issue as it is currently potentially misleading and not specific.

So my point was that by the time Tasks parsing knows enough to know whether to draw your emoji, the right thing to do is go for a full fix of the problem.

To put it another way, I believe that changing the parsing in order to solve this request is a lot of the work of solving the other request.

And I think the result of this request alone would be confusing for users. And it would be better to actually fix the rendering to show tasks than to add something confusing.

[claremacrae]

This is just to show in the query that there is something "under" the task without showing what it is.

How would Tasks know that though?

[ilandikov]

Sorry I was unclear. I was asking if it would be possible for you to edit the Summary of this issue as it is currently potentially misleading and not specific.

ah sure, but I honestly struggle to find a good formulation for this. Please, help me out here.

Why not integrating the notes in the task line?

Because Tasks was not designed to. I have labelled requests that require changes to the core Tasks code with the label scope: requires core redesign - including this one. So you can search and see related discussions, if you are so inclined...

I'd like to see in the query output an indication that the task has some notes inside it. Just a simple emoji or something like that...

Knowing that there is a nested bullet point (or task) is likely a significant part of the work of this request.

It feels to me like the better fix for the missing list items is to actually display them... It's what dataview does - and it's a serious issue that Tasks hides them (both in Reading view and in Query results view)

I think this whole thread is the source of misunderstanding. I wrote Why not integrating the notes in the task line? 1/ these are just dummy examples, sometimes notes can be pretty long and 2/ I like to keep the tasks short so that the query output is not polluted with too much info. as an argument to not putting the sub-items into the task description, check the 1/ and /2 i.e.

- [ ] #task pack the bag for a gig, keep weather in mind since if it's snowing or rainy I may need another bag to keep the gear safe -> this task is too long to read

So my point was that by the time Tasks parsing knows enough to know whether to draw your emoji, the right thing to do is go for a full fix of the problem.

I suggested emoji because it's easy to put something visible like ✅ there.

To put it another way, I believe that changing the parsing in order to solve this request is a lot of the work of solving the other request.

They are definitely connected, but for me this one is much simpler. Just add a sign that there is something under the task. How simple is that?

We can also think of this as a first towards solving the bigger issue that requires core redesign.

I haven't tried to explain

And I think the result of this request alone would be confusing for users. And it would be better to actually fix the rendering to show tasks than to add something confusing.

I don't see why this should be confusing if it is described in the docs. I mean, filter by function is complicated, but well described and not confusing.

I would also see this as an optional thing, maybe not enabled by default. This is totally up to you.

How would Tasks know that though?

I thought of a flag that is setup while reading the task. After a quick code review, I would check the next line after the current one. If it is more indented than the current, the flag is raised. This could also be the ground to work with indentation later for the #60

[ilandikov]

Many thanks for changing the summary. Your wordings are so much better every time =)

[claremacrae]

Sorry I was unclear. I was asking if it would be possible for you to edit the Summary of this issue as it is currently potentially misleading and not specific.

ah sure, but I honestly struggle to find a good formulation for this. Please, help me out here.

OK, I've had a go.

I think this whole thread is the source of misunderstanding. I wrote Why not integrating the notes in the task line? 1/ these are just dummy examples, sometimes notes can be pretty long and 2/ I like to keep the tasks short so that the query output is not polluted with too much info. as an argument to not putting the sub-items into the task description, check the 1/ and /2 i.e.

- [ ] #task pack the bag for a gig, keep weather in mind since if it's snowing or rainy I may need another bag to keep the gear safe -> this task is too long to read

So my point was that by the time Tasks parsing knows enough to know whether to draw your emoji, the right thing to do is go for a full fix of the problem. I suggested emoji because it's easy to put something visible like ✅ there.

To put it another way, I believe that changing the parsing in order to solve this request is a lot of the work of solving the other request.

They are definitely connected, but for me this one is much simpler. Just add a sign that there is something under the task. How simple is that?

I try to explain below why it is not simple (as far as I can see). Not because of the display code, but because of the parsing and storage code.

We can also think of this as a first towards solving the bigger issue that requires core redesign.

Apologies - I hadn't tried to say why this needs some major redesign in order to be implemented. I think I wrongly assumed that you were familiar with the reading code - my bad.

Currently, Tasks reads each List Item that has a checkbox independently. And creates a Task item for each checkbox line.

It does remember the indentation level (number of spaces), but nothing else about neighbouring lines.

And it stores all the Task objects in a single flat list.

As far as I understand it, even to show an emoji or similar, this issue requires changing the file parsing and Task storage to retain parent/child relationships between Tasks that are in a tree hierarchy.

And I think the result of this request alone would be confusing for users. And it would be better to actually fix the rendering to show tasks than to add something confusing.

I don't see why this should be confusing if it is described in the docs. I mean, filter by function is complicated, but well described and not confusing.

I was thinking that users would suddenly see a new Emoji in their Tasks results, that is machine-generated from code and not in their files.

Because they didn't ask for it, some will search for that emoji in their files and not find it, and be confused.

So it's likely to generate support queries asking about the new thing...

I feel that's different from filter by function, which users only see if they actively type it. It doesn't suddenly appear in their query results...

I would also see this as an optional thing, maybe not enabled by default. This is totally up to you.

I appreciate your flexibility, but adding a new preference setting is effectively a permanent requirement for Tasks to maintain that setting code forever more...

Or if it's a new command instruction, it's also a requirement to support that forever more...

How would Tasks know that though?

I thought of a flag that is setup while reading the task. After a quick code review, I would check the next line after the current one. If it is more indented than the current, the flag is raised. This could also be the ground to work with indentation later for the #60

It's possible that you have seen an implementation trick that I haven't. That would be great! But there are so many corner cases though that need tested.

I've been looking for someone to pair with on parent/child tasks for some time...

I would be pleased to pair with you, so we can work on an implementation together and hopefully I'll see what I'm missing, and what you have spotted.

Sorry, but this is such core code in Tasks, and needs extensive thought on test cases, that I would be unlikely to accept a PR that I had not paired on, all the way through.

[ilandikov]

And I think the result of this request alone would be confusing for users. And it would be better to actually fix the rendering to show tasks than to add something confusing.

I don't see why this should be confusing if it is described in the docs. I mean, filter by function is complicated, but well described and not confusing.

I was thinking that users would suddenly see a new Emoji in their Tasks results, that is machine-generated from code and not in their files.

Because they didn't ask for it, some will search for that emoji in their files and not find it, and be confused.

So it's likely to generate support queries asking about the new thing...

I feel that's different from filter by function, which users only see if they actively type it. It doesn't suddenly appear in their query results...

Ok, this is very clear now, thanks for the details. Indeed this can lean to confusion.

I would also see this as an optional thing, maybe not enabled by default. This is totally up to you.

I appreciate your flexibility, but adding a new preference setting is effectively a permanent requirement for Tasks to maintain that setting code forever more...

Right, settings are so hard to maintain and instruction seems like a better fit.

Or if it's a new command instruction, it's also a requirement to support that forever more...

I guess given this, there is not much room for any new features at all... That's more a rhetorical comment, I struggle to see how to choose which features are worth the implementation.

I would be pleased to pair with you, so we can work on an implementation together and hopefully I'll see what I'm missing, and what you have spotted.

Agreed.

Sorry, but this is such core code in Tasks, and needs extensive thought on test cases, that I would be unlikely to accept a PR that I had not paired on, all the way through.

Noted =)