add all Headings to every List-Item

[SpocWeb]

In Response to #2290 and #2325 I have prepared this minimal Prototype.
@blacksmithgu Please consider this as a basis for discussion, I am not pushing for this exact Design,
but including the Heading Hierarchy would increase the Expressivity very much.
It prepares to used Headings instead of nested Lists to manage lists or data-key-value Pairs.

This adds a new List to every ListItem containing the path of containing Headings in strictly monotonously decreasing Levels.
This forms a kind of xPath or jsonPath to each List Item
and thus helps to organize multiple Lists within the same Markdown Document in markdown.ts:

export class ListItem {
    symbol: string;
    link: Link;
    section: Link;
    /** List of all Headings 'above' this one in ascending Order, to be able to properly group List Items */
    headings: HeadingCache[];
    ...

I am unsure on how to handle the serialize(cache: ListSerializationCache): SListItem-Operation in PageMetadada.tx (line 260)
It does not seem to support the Obsidian HeadingCache Class, so I am converting it to a List of Heading-Strings
with proper number of #s to indicate the correct Heading Level
headings: this.headings.map(h => "#".repeat(h.level) + " " + h.heading),

Best Regards and thank you for this powerful component. I am aware that there are many factors to consider for the evolution of the DataView.

[nirmalhk7]

Nicely done. I'd really like to have this merged.

[charle36]

Noob question, would this allow us to build queries with a placeholder for the query's heading(s)?

If so, one use case I can see is the ability to write a query with such a placeholder and then move/duplicate it in a board (from the Kanban plugin) and have the query automatically adjust in function of the column it's in. In addition, renaming a link in the heading would adjust the links in the properties without breaking the query. That would be a nice addition! (But again, noob question!)

[SpocWeb]

renaming a link in the heading would adjust the links in the properties without breaking the query.

This could already be possible now using these task properties in dataview:

property	Type	Description
path	Text	The full path of the file this task is in. Equals to file.path for pages.
section	Link	Link to the section this task is contained in.
link	Link	Link to the closest linkable block near this task; useful for making links which go to the task.

[charle36]

This could already be possible now using these task properties in dataview:

Not as far as I know, there seems to be no way for a query to refer to its own heading or task at the moment, only its own file (with "this.").

[holroy]

This could already be possible now using these task properties in dataview:

Not as far as I know, there seems to be no way for a query to refer to its own heading or task at the moment, only its own file (with "this.").

It surely is possibly for both task and list item to refer to their section link, and access the closest heading of the given item.

This PR seems to be more on actually having the full list of headings it's under. Let's say you got an outline like H2 A | H3 AA | H2 B | H3 BB | a task instead of only seeing the H3 BB then get the full hierarchy of H2 B and H3 BB if that make sense.

[SpocWeb]

@charle36 This is the...

way for a query to refer to its own heading or task

You have to enable JavaScript Queries and possibly inline JavaScript Queries then you can access the containing header: $=dv.current().file.lists[1].header.subpath

My pull-request enables to not only retrieve this, but also all containing headers starting with the immediate header up to the top-Level Header.

[holroy]

I've still not really looked into the code, but this doesn't interfere with existing logic related to the section link, does it, @SpocWeb ?

[SpocWeb]

I've still not really looked into the code, but this doesn't interfere with existing logic related to the section link, does it, @SpocWeb ?

No, everything stays as before, I have just added a new List, so it is backwards compatible. @holroy
I only had problems serializing the List of HeadingCache Objects, so I am using strings now (unsure on how to handle the serialize(cache: ListSerializationCache): SListItem-Operation) in PageMetadada.tx (line 260)

[holroy]

I'm going to defer this until a 0.6 release, as it might interfere/relate to some other changes I'm planning for that release. I'm not sure if we should impose this information on all queries, or rather just when the users specifically asks for it. Leaning towards the latter, and hence this deferral.