Work on a more minimalistic and opinionated version of the syntax file

[fmoralesc]

I had been thinking of working on a version of the syntax file that would remove a lot of what I consider to be cruft or unnecessary. Recent discussions with @alerque made me think that I should do something about it, and here's the product of a few hours, that I can already use with some documents I'm working on. This is in no way intended to be used more widely (it's really messy already :p), but I'm sharing it in case someone wants to try it out.

Over the years, I've come to think that the syntax file tries to highlight too much (and I'm not the only one, although I am less extreme than others). My experience with acme-colors made me think that in markdown documents, it is important to highlight some structure, but not all. For example, headings are important, and it is important for me at least to keep footnotes in a different color from the main text so I can easily skip over when I read. I don't care as much about making references stand out, and I don't care at all about inlines other than pre-formatted text and italics. I don't find the highlighting of list item bullets useful. I can see that I'm dealing with a list from the shape of the text. And so on. My use case has always been geared towards the production of pdf documents through LaTeX, so currently it doesn't provide any of the usual HTML utilities.

[alerque]

I originally branched my commonmark from somewhere 50+ commits back. I just fixed that so it is off a recent master. Would you mind if rebased this branch to work with the syntax flavor flipping mechanism I used there so it's easy to go back and forth and compare changes without reloading the editor?

[fmoralesc]

Done! I added this syntax file as a separate flavour.

[bpj]

One thing which could definitely be dropped is highlighting of indented blocks which gives way too many false positives. Now that Pandoc supports fenced code blocks there is no reason not to use them!

Another is bare square brackets which in my case only gives false positives since I don't use shortcut reference links — there are way too many actual square brackets in my field! Square brackets immediately followed by another square/round/curly bracket may be another thing, but since it is problematic it should probably be optional.

I wouldn't like losing highlighting for bold, which has a meaning in my field, as does bold italic, so I would definitely want to keep that.

[fmoralesc]

@bpj I agree about indented blocks (if no elements in markdown relied on indentation thinks would be so much simpler!), but there's no way any markdown processor (like pandoc) will drop support for that syntax, and it's best to keep a way to tell that certain regions are actually going to be parsed as code blocks.

I think for brackets (and actually all sorts of inline elements) the best solution is to externalize highlighting to a proper parser. One of the original features of the syntax file was to read the document and detect the reference links that were proper, and only match those. But it was slow, so we replaced it with the regex based solution we are using now.