Improvements to task extraction

[rufuspollock]

Follow on to #60

Stuff like parsing out (like dataview):

• created: If available, the 'created' property is extracted and incorporated into the DataView result.
• due: If present, the 'due' property is extracted and included in the DataView result.
• start: If the 'start' property exists, DataView extracts and integrates it into the result.
• scheduled: DataView also considers the 'scheduled' property, extracting and including it if available.

Also maybe pulling all list items and being like dataview ...

[mohamedsalem401]

@rufuspollock
Here's how Obsidian DataView provides a way to extract fields in tasks:

1. Inline Fields Syntax:

   • Inline fields use a Key:: Value syntax in the task ( or any list item ).
   • Example:

     Basic Field:: Some random Value
     **Bold Field**:: Nice!

   • The :: double colon serves as the delimiter between the key and the field's value.

2. Bracketed Syntax for Inline Fields:

   • To embed metadata inside sentences or have multiple fields on the same line, you can use the bracket syntax and wrap your field in square brackets.
   • Example:

     I would rate this a [rating:: 9]! It was [mood:: acceptable].

3. Fields on List Items and Tasks:

   • When annotating a list item, such as a task, with metadata, you must use the bracket syntax to add fields to specific list items explicitly.
   • Example:

     - [ ] Send an email to David about the deadline [due:: 2022-04-05] [start:: 2022-04-05].

   • Bracketed inline fields are essential in this context, as they allow you to associate specific information with individual list items.

[rufuspollock]

@mohamedsalem401

Inline Fields Syntax

Don't think this is needed IMO / IME.

The useful stuff was the emoji conventions i think.

[dstengle]

I've started working on this and have a basic prototype working. I need the inline fields as well as tags in order to manage a variety of tracking elements.

It is not that difficult to add a "taskmetadata" and "tasktags" within the overall metadata field, but this kind of nesting will make sql queries get pretty awkward. I'm planning on having some kind of template or macro expansion syntax for common things but it should also be possible to use sql directly with json_extract functions.

I'd like to propose having a tasks table and bringing everything up a level so that "description", "checked", "due", "completion", "created", "start", "scheduled" are columns and "metadata" contains tags and key-value pairs. I'd also like to consider outlinks as a field as well. Dataview has an extensive set of implicit fields but these are the ones I need to get started and which would also be pretty broadly useful.

[rufuspollock]

@dstengle this sounds pretty good and we're really open to contributions.

My recommendation is that we start with whatever JS typescript object we want and then keep the export to sql cleanly separated. (That's the general approach we are going for). does that make sense?

[dstengle]

It does make sense although File vs FileInfo interfaces are confusing, for instance.

I followed the pattern and there is working code in the fork here: https://github.com/dstengle/markdowndb/tree/parse-task-inline-fields.

Take a look and let me know what should be there before I make a PR.

In making this update I had to spend a lot of time updating unit tests with all of the repetition of document data being tested.

Edit: I should note that the description extracted seems to be removing wikilinks and I'd like to have task level links as a property of Task.

I'm also conflicted about the description vs some kind of display description that doesn't have tags and fields embedded for easier display without duplicate output.

[rufuspollock]

@dstengle hey, sorry for slow reply. This looks great.

@mohamedsalem401 can you do a quick extra review to see if you have any suggestions and then we can create a PR.

In making this update I had to spend a lot of time updating unit tests with all of the repetition of document data being tested.

Are there things you think we could de-duplicate to make this better?

Edit: I should note that the description extracted seems to be removing wikilinks and I'd like to have task level links as a property of Task.

I agree. I guess we may want "raw" description and cleaned description as per your suggestion. Or maybe just nor remove formatting or wikilinks from the extracted description.

[mohamedsalem401]

@dstengle
I have seen your changes. You have done a great job 🙌
I'm just wondering whether it would be good to also include the fileID as a column for tasks.

And it would also be amazing if you updated the tests other than say.

  { description: "task 2", checked: true, metadata: {}, 
  created: null,
  due: null,
  completion: null,
  start: null,
  scheduled: null,  },

[mohamedsalem401]

FIXED. #115
Thanks @dstengle!🙌