Support standard Markdown headings

[jgclark]

This is an impressive piece of work, Rob.
I help build plugins for the flexible and extensible NotePlan app, and so am familiar with debates around Markdown syntaxes and interoperability questions between different Markdown editors.
I was surprised to find that Markdown header syntax seems to be ignored here; I would have thought it natural that the group Section syntax would instead be simply H2 ## Sections ... possibly with H3 if you want some sub-sections in future.

To increase interoperability please consider supporting this as well as group.

[jgclark]

And, while I'm at it, it would also make sense to treat an H1 line as the title (e.g. # Plan title), as well as title: Plan title.

Again, to reduce friction in interoperability, and use what Markdown already implicitly assumes about it's Headings.

[kochrt]

I'll need to think about this one.

There are definitely differences between markdown and markwhen.

I could see H1 lines as the title, and I could see H2 > H6 as section or group headings, it does kind of make sense and would be more in line with what markdown does.

I like how currently in markwhen you can specify a title and description; I also like being able to end a section with endGroup or endSection. Otherwise in markdown the section/group would include every event up to the next section/group (and maybe that's ok).

There's also a visual difference between a group and a section that I don't think markdown headers could provide, without additional syntax. Do you have ideas about how groups and sections could be differentiated in markdown?

[jgclark]

Thanks for thinking about this.

I confess I missed the distinction about MW sections on my reading of the documentation, and initial playing. It appears to be a output-only distinction, so I'd be wary about having different main syntax for it. You're using #tags to change other output-only distinctions (colour); why not have somethingn like a #fullwidth tag to keep consistency?

i.e.

group Group 1 #Education #fullwidth
...
endGroup

group Group 2 #Travel
...
endGroup

BTW are you familiar with use of frontmatter in Markdown documents? Its becoming more common among people who have more complex workflows, or who are using MD in Personal Knowledge Management systems (e.g. Obsidian).

The most common form of it, as applied to MW, could be:

---
title: Plan title
description: with a description
#Travel: blue
#Education: green
#Economics: #abc
---
## Group 1
etc.
...

[kochrt]

I was just thinking about frontmatter specifically, figured I'd write some of it down.

The problem I'm having with markwhen + frontmatter is that frontmatter should probably appear 'at the top,' so to speak, or up front. But I'm not sure where that would be with markwhen.

Should it be at the very top of the file, and only once? Should it be at the top of each page, since pages are supported? Or, since everything between one event declaration and the next is essentially markdown, could there be frontmatter with every event-isolated markdown snippet?

I think every page makes the most sense?

At the same time, though, why is frontmatter (syntax) necessary? Just for consistency? There's currently no need for special syntax to determine when we are pre-content -- we are pre-content until we see the first event. Avoiding the extra keystrokes seems nice imo.

The other benefit to not having frontmatter I could potentially see is it would make markwhen more easily embeddable into other markdown-adjacent formats. I could see a world in which markwhen is pasted cleanly into markdown, in which case the lack of frontmatter would be beneficial.

[huyz]

Frontmatter isn't the only common convention; nowadays we have inline fields that are becoming quite popular: https://blacksmithgu.github.io/obsidian-dataview/#annotation

[jgclark]

On the other hand ... most of the markdown editors I use understand frontmatter and render and/or allow different behaviour in it or from it. For example (on Mac) Obsidian, Typora, NotePlan. It also seems to be common among static site generators, which are often Markdown-based.