Make Tasks find signifiers even in there is text after them

[ArneNostitz]

Please check that this issue hasn't been reported before.

• I searched previous Bug Reports didn't find any similar reports.

Expected Behavior

filter should find tasks even if there is text after the done date

Current behaviour

filter does not find any tasks that have text after the done date

Steps to reproduce

i often write an "outcome" for a task. for example:

• check 📅 2022-12-29 ✅ 2023-01-09 > appointment 19.1.

but these tasks are not included in a

done today

search. this i use on a daily note to have an overview what i have done that day.

Which Operating Systems are you using?

• Android
• iPhone/iPad
• Linux
• macOS
• Windows

Obsidian Version

1.1.9

Tasks Plugin Version

1.22.0

Checks

• I have tried it with all other plugins disabled and the error still occurs

Possible solution

No response

[claremacrae]

Hi Arne, I understand what you are saying.

Current behaviour

This is not currently a bug - it is the current intended behaviour.

If you go to this page in the docs:
https://obsidian-tasks-group.github.io/obsidian-tasks/getting-started/#limitations-and-warnings
... and scroll down you will see this:

Finding your tasks whose data is not found

I just spent a bunch of time writing up some searches I use in my own main vault to find tasks with emoji or date problems.

It won't be published until the next release.

The rendered file is here:

• https://github.com/obsidian-tasks-group/obsidian-tasks/blob/main/docs/how-to/find-tasks-with-invalid-data.md

You can see the raw file here, for pasting in to Obsidian:

• https://raw.githubusercontent.com/obsidian-tasks-group/obsidian-tasks/main/docs/how-to/find-tasks-with-invalid-data.md

Making this in to a feature request

Like I said, this is not a bug, it is the intended and documented behaviour.

However, I do agree that it would be kinder to users if Tasks were more permissive in the order of text that it accepts.

Therefore I will convert this ticket from a Bug to a Feature Request, so that it can be tracked as a possible future enhancement for Tasks.

[ArneNostitz]

Thanks @claremacrae for clearing this up for me - yes it would be really great to have this behaviour change :) ... it is somehow also connected to the key:value pair request as this could be a custom key "Outcome" for example. so a task can have an outcome that is a note or a link to another task or whatever.

as I don't know the structure of the code its probably more complicted than a few lines - especially as this is something that has influence on the modal and probably some other parts of the interfaces and query structures.

in any way - thank you so much for making a feature request out of it and I stay tuned. have a great day

[claremacrae]

Picking up a thread with @zaphodb2002 from #1795 (comment)

@claremacrae For future reference, this is the same as issue #1505 , yes? I'll go take a look at that one.

HI @zaphodb2002, many thanks for (I think) looking at this.

Just to let you know, however, that it is currently not a very good time for anyone to work on this issue...

The reason is that @kedestin is currently doing a lot of work on refactoring out the task line parsing code - the current step being #1773. See their earlier PRs...

There will then be support for one or more new formats added (I think, a non-emoji-based one) - and I can envisage a number of unresolved questions about this already.

I am especially keen to see how the new abstractions will work in adding support for dataview task fields, as that is a frequent request from Tasks users.

And I think having two separate strands of development of parsing at the same time would be inefficient for contributors, and likely too much for me to keep track of at the same time.

So far as this issue goes, I suggest seeing how @kedestin's work goes, and what evolves from that first.

And then explore removing the order-of-field limitations - unless of course that is driven by a requirement of one of the other formats which we already have requests for. (Like if users of dataview already have tasks lines with descriptions mixed in amongst task properties)

[claremacrae]

In case it helps anyone else, I have a 'report problems' note that I check once a week, that has two searches - one of which is specifically to find problems with field order:

```tasks
# Find tasks with un-parsed signifiers - fix by moving fields after description
(description includes ⏫) OR (description includes 🔼) OR (description includes 🔽) OR (description includes 📅) OR (description includes ⏳) OR (description includes 🛫) OR (description includes ✅) OR (description includes ➕) OR (description includes 🔁)
group by path
```

```tasks
# Find tasks with invalid dates - fix by editing markdown, NOT by editing tasks in modal
# (as modal does not show the original broken dates)
(done date is invalid) OR (due date is invalid) OR (scheduled date is invalid) OR (start date is invalid) OR (created date is invalid)
group by path
```

/CC @zaphodb2002

[claremacrae]

Picking up the discussion from #1913 (comment)

Fro @kedestin:

If we recommend two spaces, I think auto-suggest and the Edit task modal will need to be changed to write two spaces out.

I'll see what I can do

The problem currently with the comma idea is that it prevents Tasks parsing the fields...

If we were to fix the parsing to allow text in between fields, as is requested elsewhere, I think that after the user has edited the task, the current code would put all the fields/properties after all the commas and the problem would reappear again.

I had already started on implementation of #1505 and have a proof of concept working, but dropped it soon after realizing that it:

• Would probably also require that Tasks is smart about how it edits an existing Task: If a user uses the edit modal to update the due date of - [ ] This task is [due::2023-04-25] and has [priority::high], the expectation would probably be that the position of the due date is preserved within the task. This could be implemented by:

  • Preserving signifiers in a task description, so you can keep track of where they were. (This is a breaking change)
  • Adding a bunch of bookkeeping so that signifiers continue to be removed from descriptions, but we know where they were.

• Would likely require a full rewrite of DefaultTaskSerializer, DataviewTaskSerializer and a partial rewrite of whatever code depends on DefaultTaskSerializer.componentToString.

  • Parsing recurrences in arbitrary positions in the emoji format is particularly challenging given that it's natural language text, and the parsing code is owned by a dependency.

There may be more that I'm not remembering off the top of my head.

I'd rather not leave folks in a poor state w.r.t Dataview support, so I'd be willing to keep working on this if we decide it's the best course of action.

[claremacrae]

I had already started on implementation of #1505 and have a proof of concept working, but dropped it soon after realizing that it:

Thank you.

• Would probably also require that Tasks is smart about how it edits an existing Task: If a user uses the edit modal to update the due date of - [ ] This task is [due::2023-04-25] and has [priority::high], the expectation would probably be that the position of the due date is preserved within the task. This could be implemented by:

  • Preserving signifiers in a task description, so you can keep track of where they were. (This is a breaking change)

I had thought the the code might evolving evolve to this state eventually, but was not expecting to get there for quite some months if at all.

I do agree that it's a lot of work.

[reagle]

BTW: if you consider non-emoji syntax, I recommend Zim conventions:

A due date is prefixed by a "<": you must complete the task before that date.
A start date is prefixed with ">": you should start the task after that date.
the more exclamation marks the higher the priority

[claremacrae]

Just to note, @eatgrass has done really lovely experimentation on possible approaches for this, in:
https://github.com/eatgrass/obsidian-tasks-deserializer

[claremacrae]

A key part of this, usability-wise, will be retaining the original text order when editing task fields. That still requires thought, and should probably be implemented before the more general parsing...