In the following code sample, I assume that [ref] becomes a hyperlink (shortcut reference link).
However, (in commonmark.js dingus) it does not.
[ref][sometext`code]`
[ref]: ddd
If I remove “]” from code, it works as expected.
May it be a bug? I believe code span content must not affect link definitions.
I re-read the spec about links and code spans, and I think it is unclear about a precedence, and it does not include code samples on this topic.
It explains that code spans have higher priority than links.
However, as I can see in commonmark.js dingus, it is true only for link text.
For inline links, link target and link title have higher priority than code spans:
[link](`fo)o`
In this example, this is a link + “o`” text, not code span. This is not mentioned in the spec (if I am wrong, please correct me).
And for reference link, intersection with code spans is not processed correctly, as it is shown in my previous message.
It’s clearly a bug. Compare:
[ref][sometext code`]`
[ref]: ddd
with:
[ref][sometext code
[ref]: ddd
Also, note that some CommonMark parsers, including MD4C and Markdown-it, parse it correctly.
No, I don’t think it’s a bug. Have a look at the definition of “link label”:
A link label begins with a left bracket (
[) and ends with the first right bracket (]) that is not backslash-escaped. Between these brackets there must be at least one non-whitespace character. Unescaped square bracket characters are not allowed inside the opening and closing square brackets of link labels. A link label can have at most 999 characters inside the square brackets.
By this definition
[sometext code`]
is a link label.
[sometext`code] would be a valid link if this label was defined.
In this code, a valid link is inserted:
[text][sometext`code]`
[sometext`code]: eee
(I was wrong in my second post, “`” has lower priority than “]” in a link label, so it is consistent with preferences of link target and title).
But the bug in my initial example is different.
It is converted to:
<p>[ref][sometext<code>code]</code></p>
But it should be converted to:
<p><a href="ddd">ref</a>[sometext<code>code]</code></p>Your first case was:
Here we have bracketed ref followed by a link label [sometext `code].
Since that label does not have a definition, this is not a link.
You might think, shouldn’t it be a shortcut reference link to ddd followed by plain text [sometext and then code code]? This is ruled out by the spec:
A shortcut reference link consists of a link label that matches a link reference definition elsewhere in the document and is not followed by
[]or a link label.
Since [sometext `code] meets the condition for being a link label, this isn’t a shortcut reference link. Does that make sense?
I think this is the reason why the parser does it in this way.
However, I believe that this behavior is inconsistent, because unresolved labels are never treated as labels.
You said originally that you thought it was a bug. Since this behavior is required by the spec, it is not a bug. Instead, you just don’t like this aspect of the spec.
If we were going to change anything in this area, I’d actually prefer to go in the opposite direction, so that structure is less dependent on whether labels are defined. See
https://johnmacfarlane.net/beyond-markdown.html#reference-links.
But all things considered I think it’s fine to keep things as they are.
Initially, I did not say that it is a bug, I asked “may it be a bug?” )
I think the both ways are ok.
I just wish the specification to be more clear on this topic, explicitly saying that a shortcut link is not created when a list text is followed by an unresolved link label. I think it is not obvious.
Sergey Tkachenko via CommonMark Discussion
noreply@talk.commonmark.org writes:
I just wish the specification to be more clear on this topic, explicitly saying that a shortcut link is not created when a list text is followed by an unresolved link label. I think it is not obvious.
Agreed, this would be a good candidate for an addition clarifying example. Could you put up on issue on the GitHub tracker so we don’t forget? (commonmark/commonmark-spec).
I found that example 567 demonstrates this issue:
[foo][bar][baz]
[baz]: /url1
[foo]: /url2
( foo is not a link here because bar is not defined)
So no additional examples are needed, sorry.
But probably, examples that show preferences of link destination, link title, and link label (in full reference links) over code spans, autolinks and html tags would be useful…