There is indeed a problem with fenced code. It’s the only instance of a block where it’s continuation
is implicitly stated, at the same level as paragraph, and therefore requires backtracking.
A blockquote continuation is explicitly stated using > in front of every line, indented code blocks are explicitly stated using the spaces in front of every line. Paragraph continuation are implicitly stated because they are the default blocks unless other blocks are explicitly stated.
As I see it, the purpose of fenced code block is to facilitate introducing code in a Markdown document, it is basically an easier alternative to indented code blocks which were part of the original specification. GitHub introduced it because they are a “code” oriented company and wanted to facilitate this particular use, but I don’t see any important reason why CommonMark should follow this path other than compatibility.
Here are the options I can see:
-
Introduce backtracking in the reference implementation, which may be difficult and impact performance
and security but would bring a cleaner syntax parsing philosophy. I am not aware that much of the reference implementation but there must be a way to backtrack efficiently. Basically to parse in a pessimistic way: when encounter a fence, consider it as a possible fenced code block but continue parsing as normal until we see another fence, we thenpop()the last fence and create one fenced code block and replace the parsed nodes from the first fence with the newly created fenced code block. I don’t see any big performance impact here… or… -
Remove necessity of backtracking for fenced code blocks by requiring explicit block continuation like it is done for other kind of blocks. CommonMark is already distancing itself from the original specification by using fenced code blocks but I think it would be better aligned with it by using the “explicit block continuation" philosophy of the first specification by John Gruber.
The one I can think of right now is the following:
``` swift
```
``` func test() {
```
``` }
or simply:
` swift
`
` func test() {
`
` }
It’s not as simple as the previous fenced code blocks syntax but it has the advantage of being clear and
force the user to state explicitly his intention. Any other suggestions would be welcome!
Note: It would also solve this problem: