Just to be clear with anyone that is seeing me post “how about this Markdown” posts. I am writing a Markdown linter and getting around to most of my corner cases. While 99.5% of the scenarios that I come up with parse fine, the ones I ask about here are ones that I am trying to figure out the “right” thing to do.
So, going through and validating another round of tests, and came across this pair of tests.
[
foo]: /uri
[
foo]
(note the two space characters after the open and before the newline) which parses to:
<p><a href="/uri"><br />
foo</a></p>
However, if instead of the two spaces I use a single backslash:
[\
foo]: /uri
[\
foo]
I get:
<p>[<br />
foo]: /uri</p>
<p>[<br />
foo]</p>
Now, based on conversations in this topic, I believe it would be correct to say that reference parser tries to handle this as the first part of a paragraph. It’s just a guess, but I would think that it has an issue with a single backslash and aborts the Link Reference Definition?
You get with what implementation? I cannot reproduce. (Tried with cmark and MD4C.)
I don’t think so: Even if its first parsed as a paragraph, its beginning (in this case all of it) has to be tested whether it satisfies all the rules for the reference definition. I believe it does. Nothing forbids a backslash in the link. ref. def. label. So, it’s ripped from the paragraph and treated as a link ref. def. (before the rest of it is even passed to an inline processing).
@jgm based on the answers I am getting from BabelMark, which projects should I file a bug report to?
As I said before, commonmark.js. Some of the others you mentioned aren’t even trying to target commonmark (e.g. cheapskate, which is also unmaintained).