fix(core.summary): bugs + flexibility around incomplete metadata

[laher]

A few bugfixes & added flexibility, after trying to use :Neorg generate-workspace-summary on my workspace.

Bugs and inconveniences

• Currently the metadata strategy is making assumptions about the metadata in your doc, and failing with an error if specific key is not present.

  • e.g. if you :Neorg inject-metadata and your metadata doesn't specify a description or categories, then it just errors.
  • If you don't have a title, you get nothing.
  • It also doesn't like numeric titles like in a journal, e.g. I had 06 for 6th May. It fails in this case too.

• The generated summary always uses a ** heading regardless of what level of heading your cursor is on.

• If you have inconsistent title casing in your metadata categories, the alphabetic ordering doesn't work (even though the categories are rendered with title case)

Fixes

• Avoid errors when category or description or title is vim.NIL or numeric. I made a default category 'Uncategorised' for .norg files without a category, and I gave a default title of vim.fn.basename(filename) if none was defined.
• Heading is now 1 deeper than the node under cursor.
• Categories are title-cased before being sorted by vim.spairs().

Results

Some example output. My cursor was over the ** Summary heading.

index.norg was the only file in my workspace with a category (homebase) in the metadata, and it didn't have a title. Those journal entries had a numeric title like 06, etc.

** Summary
*** Homebase
   - {:/Users/xxx/notes/work/index.norg:}[Index.norg]
*** Uncategorised
   - {:/Users/xxx/notes/work/main.norg:}[Neorg Notes]
   - {:/Users/xxx/notes/work/journal/template.norg:}[Template]
   - {:/Users/xxx/notes/work/journal/2023/05/06.norg:}[6]
   - {:/Users/xxx/notes/work/journal/2023/05/07.norg:}[7]
   - {:/Users/xxx/notes/work/journal/2023/05/08.norg:}[8]
   - {:/Users/xxx/notes/work/journal/2023/05/18.norg:}[18]

[laher]

I'm also wondering ...

Maybe whenever this metadata strategy doesn't find a metadata.title, it could just read the first heading instead and use that. Then at that point, do we even need a headings strategy? Maybe just remove the strategy concept altogether & represent all files in the workspace (maybe there could be configurable globs for inclusion/exclusion, and/or maybe document metadata tags for exclusion too).

It's not something for this PR, but it's my 5c after using the module a little bit.

[vhyrro]

Thanks a lot for this! I think strategies are still useful in terms of long-term extensibility (there may be more interesting strategies like sorting by GTD context etc.), but I agree we could refactor the metadata strategy into maybe a default strategy that pulls from both the metadata and the first heading as a fallback? Would be more flexible that way :)

[laher]

nw

I think strategies are still useful in terms of long-term extensibility (there may be more interesting strategies like sorting by GTD context etc.)

Makes sense, thanks for sharing the vision

but I agree we could refactor the metadata strategy into maybe a default strategy that pulls from both the metadata and the first heading as a fallback? Would be more flexible that way :)

Cool, I'll give it a shot sometime