feat: Parse dataview compatible dates

[j6s]

Description

Adds the ability of using the following prefixes instead of emoji:

• start::
• scheduled::
• due::
• completion::
• recur::

These are the same that are supported by the dataview plugin: https://blacksmithgu.github.io/obsidian-dataview/data-annotation/#tasks

Note: The last one is not found in dataview, I made that one up

Motivation and Context

Coming from zim's tasklist plugin, I missed the ability to fully type out a task without having to type special characters or wait for intellisense to pop up - both of which I feel like break my 'flow' of typing. I quite like zims format of using > for start dates and < for due dates (e.g. - [ ] do the thing > 2022-10-10 < 2022-10-31) but suspected that this would produce a lot of parsing errors / difficulties.

Through searching Issues & Discussions, I found a couple of threads mentioning dataviews tasks and one where it was mentioned, that parsing them would be implemented at some point (https://github.com/obsidian-tasks-group/obsidian-tasks/discussions/373 / https://forum.obsidian.md/t/task-management-devs-define-a-shared-date-and-action-format/26464/78)

How has this been tested?

I implemented a unit test for this

Screenshots (if appropriate)

not applicable

Types of changes

Changes visible to users:

• [ ] Bug fix (prefix: fix - non-breaking change which fixes an issue)
• [x] New feature (prefix: feat - non-breaking change which adds functionality)
• [ ] Breaking change (prefix: feat!! or fix!! - fix or feature that would cause existing functionality to not work as expected)
• [ ] Documentation (prefix: docs - improvements to any documentation content)
• [ ] Sample vault (prefix: vault - improvements to the Tasks-Demo sample vault)

Internal changes:

• [ ] Refactor (prefix: refactor - non-breaking change which only improves the design or structure of existing code, and making no changes to its external behaviour)
• [ ] Tests (prefix: test - additions and improvements to unit tests and the smoke tests)
• [ ] Infrastructure (prefix: chore - examples include GitHub Actions, issue templates)

Checklist

• [x] My code follows the code style of this project and passes yarn run lint.
• [x] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [x] My change has adequate Unit Test coverage.

Terms

• [x] My contribution follow this project's contributing guide
• [x] I agree to follow this project's Code of Conduct

---

Notes:

• I am not 100% happy with the docs I added, maybe someone else has a better idea for this. Maybe just make an 'alternative formatting' page?
• Thank you for having extensive tests for this code base. It made it very easy to judge the extent of a change even when I was completely new to the project.

[claremacrae]

Hi @j6s, Many thanks for this. I am sure it will be a very popular addition.

I am not currently able to try it out, so will have some more comments when I can.

From reading the code, I am wondering:

Format parsed

It will be important that the Tasks behaviour matches, as much as possible, the dataview behaviour on the save markdown content.

Have you compared the results of your new version of Tasks with the results from the equivalent dataview searches?

I ask because the format you use is different from the documented dataview format: https://blacksmithgu.github.io/obsidian-dataview/data-annotation/#tasks. It uses square bracket around values. I think it also allows some other syntax, perhaps parentheses around inline fields.

So in your test cases, I actually think Tasks should not recognise any of the example dates, because none of them have [] so are not valid dataview inline fields, as far as I understand.

Behaviour

What happens when you complete a Task with dataview fields? I presume you get an emoji-based completion date. Do you think this is OK? Do you think that it should at least be documented?

What happens when you use the Add or edit Task modal to change one of these values? I suspect the task would be re-written with emojis.

What happens when you view these tasks in Live Preview or Reading mode. I wonder whether the Tasks rendering code will re-draw them with emojis rather than the dataview-like format that is currently parsed.

[claremacrae]

There is an old, partial PR - #384 - that might be worth looking at, to see if it has any code that would help with this PR, or if it could be picked up and finished off.

[claremacrae]

So in your test cases, I actually think Tasks should not recognise any of the example dates, because none of them have [] so are not valid dataview inline fields, as far as I understand.

I think it’s a bit more complicated than I first thought. I’m not totally sure of this, but from my experimenting it seems that the square brackets are not required for recognising fields in free text, but they are required for recognition in task lines.

[claremacrae]

Hi @j6s,

Thank you again for the contribution.

Just to update on the current status, I didn't pick this up at the time, because of the unanswered questions above...

However, now that we have an abstraction for reading and writing tasks in different formats - see #1728 - I expect that the best approach for this functionality would be to use that abstraction to fully define a new Dataview format for reading and writing tasks in Dataview format.

The questions above about when/if [...] are needed will remain, I suspect.