Fenced codeblocks

[tpoisot]

There are a number of issues with fenced code blocks (in existing packages).

1. Language detection. For exemple, if I write ~~~ langname, unless there is a rule that imports language-langname, there is no highlighting. Solving this would be awesome, but I'm not sure how.
2. Different syntaxes for blocks. For example, the simplest is gfm, which uses ~~~ langname. But many other (pandoc, notably, as well as packages like knitr, Judo, ...), use ~~~{.langname key=value key=value}. Ideally these would be detected, and parsed.

I can try my hand at some of these, but I have the feeling that solving point 1 would allow to work on point 2 in a more general way. Ideas?

[burodepeper]

@leipert had an idea for this. I believe he wanted to import possible languages via a .cson file, and integrate it via dynamically created grammar. I think that fixes everything, and the reference file could be easily updated to add support for additional languages.

[tpoisot]

Happy to look at the code as soon as there is some. I use an absurd quantity of fenced code blocks, so I have a lot of motivation to make it work right.

[burodepeper]

Okay, I'll put some extra work into it ; ) Could you (privately) send me some of your Markdown files that give issues? It would be good to have some complex, realistic testing material.

[tpoisot]

Here is a simple example: https://gist.githubusercontent.com/tpoisot/9b14781225b2f37a259c/raw/2136d1d0d29a14f3e756f7b8bfa5f90bc3721531/test.md (it renders fine on github: https://gist.github.com/tpoisot/9b14781225b2f37a259c)

[burodepeper]

@tpoisot I've been looking into fenced-code-blocks. Foremost to eliminate the abundance of copy-pasted grammar. I think I have that figured out now (although I'll probably improve performance a bit later on).

I've been thinking about the two points you mentioned. I think I know a way to implement the first. I'd like to solve it in pure grammar (performance-wise) and not rely on runtime code, but it relies on how flexible the first-mate package is, so don't get your hopes up just yet. Your second point is on the todo-list as part of the CommonMark spec. As you can see in #19, even github fails to render the third example correct, but it shouldn't be too difficult to implement. The key=value parsing you mention, is that somewhat standardized markup? CommonMark is a bit vague on it, and basically says to 'ignore' everything after the first word. See http://spec.commonmark.org/0.22/#example-100

[burodepeper]

The ~~~{.langname key=value key=value} variant will probably be implemented as part of an extension/flavor. Still working out why the php isn't recognized, weird.

[burodepeper]

Also, the first issue you mentioned isn't possible in the easy way I had hoped.

[tpoisot]

I played with this too (re. Issue 1), but short of looking for installed atom packages, and generating the grammar when the package is initialized, but this comes with an awful overhead. So let's agree to not even consider this approach.

Awesome work, for the rest.

[burodepeper]

Agreed. I intend to publish a new version (with fenced code blocks) later today.