Strict CommonMark syntax collaboration

[alerque]

Hey! Congrats on what is arguably the best vim syntax for Markdown. And I say that as a developer of one of the competitors, vim-pandoc-syntax! (I'm also the maintainer of nerdcommenter, tagbar and some other things you may have heard of plus a few you haven't.) I often switch back and forth between plugins because they have different strengths and weaknesses. This plugin has more complete and robust Markdown syntax support in general, and I especially appreciate the good embedded code block support. The Pandoc specific plugin has some advantages in integration with Pandoc and a few syntax treatments I prefer, but it is also less robust and even missing a few basic features one would expect.

Bugs reports against its glitch ridden rendering tend to pile up. Frankly for my own purposes I often just switch to this plugin and ignore the issue reports! But that's not a perfect solution either. I miss some of the Pandoc related integrations and the emphasis on its flavor.

Recently I've been following the development of the CommonMark spec. Given the momentum behind it already I believe there will be even more convergence on this flavor in the future. Obviously given the Pandoc developers' involvement in the spec and upcoming new Haskell parser for Pandoc it is likely to become the de-facto flavor preferred by Pandoc at some point in the future too. That influences what I'm willing to sink my time into as far as plugin support. I'm also looking at standardizing the publishing house I work at on using CommonMark sources instead of our current Pandoc-ish flavor.

I would like to ask (@plasticboy, or active current contributors? @shirosaki? Others?) if anyone has any input on this situation. Have you considered making a mode or variant syntax that is strict about following CommonMark and aims to target all its features? Is this something you'd be interested in collaborating on?

To date we're really only thrown around ideas for how to accomplish this. We've wanted for a long time to find a way to get away from the RegEx based approach and use a real parser's AST to inform the syntax as well as other command features (see https://github.com/vim-pandoc/vim-pandoc-syntax/issues/300) but given that isn't possible using Pandoc yet (although it might be from cmark, and it will eventually be when Pandoc switches to commonmark-hs for parsing internally) we've also been toying with the idea of a rewrite either with stricter expressions or possibly using LPEG (see https://github.com/vim-pandoc/vim-pandoc-syntax/issues/327) or even working on an LSP driven variant (see https://github.com/vim-pandoc/vim-pandoc-syntax/issues/329).

I would love to see robust syntax support for a strict CommonMark flavor, and since nothing like that is out there yet I wanted to propose some sort of collaboration between interested parties. Does this interest you?

[ghost]

I support the need for a single strict CommonMark syntax.

[alerque]

As of #567, this plugin has been migrated to the @preservim namespace to be a collaborative effort between interested contributors. I'll be facilitating things but trying not to dictate. I would say there are two goals here which don't easily mesh:

1. Make sure this plugin is well cared for and that any changes don't significantly disrupt existing users. This means bug fixes and non-disruptive features and cleaner code and tests and such, but not a major change in direction.

2. The need for a really good CommonMark syntax plugin going forward (which is not necessarily where this plugin was going originally).

c.f. my comment on #120 regarding the target of this plugin.

[adrian5]

I applaud this effort Caleb!

[sisrfeng]

Some notes: The issue author wrote this in 2020: https://github.com/alerque/vim-commonmark,

the syntax is not cobbled together from regular expressions but informed by a real parser, it will only ever highlight 100% valid CommonMark syntax (no false positives!).