To me, it looks like the question is if <b is a valid link destination.
Spec 0.27 says:
A link destination consists of either
a sequence of zero or more characters between an opening < and a closing > that contains no spaces, line breaks, or unescaped < or > characters, or
a nonempty sequence of characters that does not include ASCII space or control characters, and includes parentheses only if (a) they are backslash-escaped or (b) they are part of a balanced pair of unescaped parentheses that is not itself inside a balanced pair of unescaped parentheses.
… and I would say that it totally fits the description of the second point, doesn’t it?
So why does no CommonMark implementation in babelmark2 recognize it as such?
So why does no CommonMark implementation in babelmark2 recognize it as
such?
<b)c> is a valid link destination. But in an inline link,
the link destination must be followed by a closing
parenthesis, and it isn’t in your example.
Thanks @jgm, I appreciate your answer, but it doesn’t really answer my question. There is no doubt that <b)c> is a valid link destination, but that should be irrelevant to my question, shouldn’t it?
As far as I understand the current spec, [a](<b)c> should be parsed as an inline link followed by a literal c>, just as many non-CommonMark parsers do it.
I don’t see a reason why <b shouldn’t be a valid “link destination” in this case, since it perfectly satisfies the second condition (after the first condition fails to match).
So this is either a bug in all CommonMark implementations or I’m mistaken.
Latter seems to be more likely, so please tell me where I’m wrong!
Thanks [2]@jgm, I appreciate your answer, but it doesn’t really answer
my question. There is no doubt that <b)c> is a valid link destination,
but that should be irrelevant to my question, shouldn’t it?
As far as I understand the current spec, [a](<b)c> should be parsed as
an inline link followed by a literal c>, just as many non-CommonMark
parsers do it.
I don’t see a reason why <b shouldn’t be a valid “link destination” in
this case, since it perfectly satisfies the second condition (after the
first condition fails to match).
Apologies. I misunderstood your point. Yes, there is an
issue here; whether spec or implementations should be fixed
is less clear… It would be useful to put an issue on
the CommonMark tracker.