Aidan Woods

Is the example right here? ``` [maybe link and maybe not](/url 'title with backtick`') ``` I can't see why this would be anything other than a link (there is no...

IMHO, since the spec states > A [link text] consists of a sequence of zero or more inline elements enclosed by square brackets (`[` and `]`). > A [link destination]...

For reference, the parser I'm working on produces (and therefore my opinion of the correct output based on my interpretation of the spec) is: ``` [maybe link and maybe not](/url...

> @aidantwoods I disagree with your conclusions. The specs talks **only** about priority of the link text You're correct there, I'm merely making an observation that [code span]s (mainly because...

@mity No worries, perhaps I could have made that clearer – apologies for the ambiguity.

@mity small correction > This isn't something that can be backed up by the spec at this time (because as you've pointed out, [code span]s only have higher precedence than...

@mgeier > In cases where those two rules clash, there has to be some tie breaker. > And I think it makes sense that whatever starts first in the input...

@mgeier > That's exactly what I'm trying to say: the "active" character doesn't have to be the first character of an inline element!... for emphasis it is any "potential closer"...

@mgeier > > > [...] the "active" character doesn't have to be the first character of an inline element! [...] for emphasis it is any "potential closer" (which can be...

~~A parser I'm producing based off the specification produces gives the same result.~~ ~~That to say, the current behaviour does honour the specification IMO~~ ~~That said, given that understanding this...