Parsing strategy for tables?

My test table extension (https://github.com/MathieuDuponchelle/cmark/commits/extensions_draft_3, https://github.com/jgm/cmark/issues/100) fails to parse the first sample, as the “setext-like” line is correctly interpreted as 2 columns, and the first line is “incorrectly” interpreted as being 3 columns.

I can imagine a solution out of this though, that preserves the block / inlines parsing separation, it’s a pretty nitpicky interpretation of the rules though:

It is postulated that blocks bind more closely than any inline parsing rules, it could thus be considered “legal” to do the following:

Change the first line to :

`Column1 \|` | Column2

At block parsing time, we could decide to interpret the backslash as an escape character, even though the rule in inline code nodes is to not interpret these. As we do match (and with two columns now, yay), we remove the backslash character for the inline parsing phase. Would that be too much bending of the rules?

1 Like