Positions of fenced vs. unfenced code

[pjeby]

Hi. I'm in the middle of switching from marked to mdast for parsing in my mockdown library. I've run into a slight snag, however, which is that mdast gives the start position of a fenced code block as the line where the backquotes are, but gives the start position of an indented code block as the line where the actual code starts.

When I was using marked, this wasn't a problem because I could detect the absence of a lang property to know that a code block was indented rather than fenced, and the presence of the attribute (even if null) to know when I need to offset the code's line position by 1. But mdast creates the property with a null value on indented blocks as well as on fenced ones, so there is no way for me to know whether to offset the line number.

Well, technically, there is: I can count the number of lines in the code node's value, and compare this to the number of lines in the node's position range, and if it's 2 less, I know it's a fenced code block and can offset the start position of the code accordingly.

This seems a bit fragile, though, so I was wondering if there can be some official way to do this. That is, to either be able to tell the two kinds of code blocks apart (e.g. via a fenced property), or to have the position of a code block be registered as the position where the code starts, rather than the position where the code's block wrapper starts.

Heck, just allowing an empty string for lang when it's a fenced block without a language would work for me. The main point is just to have an officially supported way to be able to know what line number the actual code of a code node begins on, whether the block is indented or fenced.

Thanks!

[wooorm]

Thanks for the issue, and the work you put into writing it down nicely. This is planned already, along with many more different “styling” options on nodes in GH-32 (code nodes have a boolean fences property).

However, I cannot yet reliably give a date for when I have the time to implement this (it warrants a rewrite of stringification settings and some new plug-ins along with a rewrite of the parser). This means I suggest, until GH-32 is closed, to roll your own detection mechanism. Sorry!

P.S. I’ll close this in favour of GH-32.