Reference links: Spaces between text and label

[van-de-bugger]

Inline links:

An inline link consists of the link text in square brackets, followed by the URL in parentheses. ... There can be no space between the bracketed part and the parenthesized part.

Reference links:

The link consists of link text in square brackets, followed by a label in square brackets. (There can be space between the two.)

Syntax of inline links is similar to syntax of reference links: two parts enclosed into brackets. The only difference that the second part of an inline link should use round brackets (aka parentheses) while the second part of a reference link should use square brackets.

However, inline links do not allow spaces between parts, while reference links do. I would say it is not consistent.

Several times I made the same mistake:

[a] [b]
...
[a]: ...
[b]: ...

I expected [a] [b] would be interpreted as two shortcut reference links (because they are separated by space), but pandoc v1.15.2.1 interprets it as single link [a][b]. The case is even more confusing if links are separated by newline:

[a]
[b]

pandoc still interprets it as [a][b].

I would request pandoc does not allow spaces between text and label. It will look natural and consistent with inline links.

[jgm]

Here we're just following the vast majority of Markdown
implementations:

http://johnmacfarlane.net/babelmark2/?normalize=1&text=%5Bhi%5D+(ho)%0A%0A%5Bhi%5D+%5Bho%5D%0A%0A%5Bho%5D%3A+url%0A

Moreover it's explicit in John Gruber's syntax description
that the () part of an inline link must occur immediately
after the brakceted part, while in reference links a space
may be inserted.

[van-de-bugger]

I see Gruber explicitly allowed spaces between text and label. Did he left any rationale for this decision?

Also, note a subtle difference: In Gruber's markdown syntax, label is a must, while pandoc (with shortcut_reference_links extension (which is enabled by default)) makes label optional.

[jgm]

+++ van-de-bugger [Dec 27 15 01:41 ]:

I see Gruber explicitly allowed spaces between text and label. Did he
left any rationale for this decision?

Not that I know of.

Also, note a subtle difference: In Gruber's markdown syntax, label is a
must, while pandoc (with shortcut_reference_links extension (which is
enabled by default)) makes label optional.

Yes, though Gruber implemented the shortcut style in the
last version of Markdown.pl he put out (in 2005?).

I agree that the presence of shortcut references makes the
space potentially problematic. I'm not sure what to do
about it, though, since changing this now risks breaking
lots of existing documents in ways that might not be
obvious.

[jgm]

I suggest you bring up this issue at
http://talk.commonmark.org.

We're trying to get a rationalized specification of
Markdown, and eliminating this quirk might make sense.

[van-de-bugger]

This issue was brought up about a year ago: [Why are whitespaces allowed after reference link [] [] label but not for inline links ?](http://talk.commonmark.org/t/why-are-whitespaces-allowed-after-reference-link-label-but-not-for-inline-links/447)

[van-de-bugger]

I see that space is prohibited in current CommonMark spec, and pandoc --read=commonmark (v1.16.0.2) follows the spec. However, pandoc --read=markdown still interprets [a] [b] as one link.

Could you please clarify your intention? Will you fix markdown reader behavior or keep it for compatibility with older versions?

[jgm]

I'm tempted to change this. Slightly worried that it will break some existing documents. Perhaps this should be raised on pandoc-discuss.

[jgm]

I've started a thread on pandoc-discuss
https://groups.google.com/d/msg/pandoc-discuss/gL036hutGL4/kZq9ISjABgAJ

[davidar]

If breaking existing documents is a concern, perhaps another option would be to move support for spaces into a (disabled-by-default) extension?

[jgm]

Yes, we could add an extension for this; maybe that's the best approach. +++ David A Roberts [Apr 30 17 01:56 ]:

…

If breaking existing documents is a concern, perhaps another option would be to move support for spaces into a (disabled-by-default) extension?