Expose reference links

[commonmark]

Expose reference links

[jgm]

The AST does not contain nodes for reference link
definitions. When these are parsed, the reference map
is updated, but no node is created. Hence they cannot
be reconstructed.

One possible change would be to store the reference key
(if any) in the AST node for the link, together with the
destination and title. The commonmark renderer could
be trained to create a reference-style link when there
is a non-empty value for the key.

Of course, there would be no information about where
the definition was in the source document, so some
rearranging might occur. (Presumably all the reference
definitions would go at the end of the document.) But
some changes in the commonmark document are unavoidable,
since there are many details that the AST doesn't store
(e.g. what kind of delimiter, _ or *, was used for
emphasis, and whether a link was created using an autolink
or a regular inline link).

+++ krousey [Jul 13 15 11:54 ]:

It seems the parser automatically looks up references and turns them in
to links. It would be nice to have a way to see the actual references
and their definitions so we can use this library to programatically
manipulate markdown documents without having all the references
collapsed.

example:

./cmark --to commonmark <<EOF
[foo] bar

EOF
foo

—
Reply to this email directly or [1]view it on GitHub.

References

1. #64

[krousey]

So the idea is I would get back a link node, and it would have reference information in it? And then the cmark renderer would collect these as it output references and emit the reference definitions at the end? If so, that sounds great. Some modification occurs, but no explosion of link definitions.

[jgm]

+++ krousey [Jul 13 15 13:34 ]:

So the idea is I would get back a link node, and it would have
reference information in it? And then the cmark renderer would collect
these as it output references and emit the reference definitions at the
end? If so, that sounds great. Some modification occurs, but no
explosion of link definitions.

Yes, that's the idea.

[pickfire]

Actually, why doesn't <//domain.tld/> be render as <a href="//domain.tld/">//pickfire.tk/</a>? Is this a bug? I am not sure if I should open a new issue as this.

[kivikakk]

@pickfire: the scheme is required by the spec; see 6.7 Autolinks:

An absolute URI, for these purposes, consists of a scheme followed by a colon (:) followed by zero or more characters other than ASCII whitespace and control characters, <, and >. If the URI includes these characters, they must be percent-encoded (e.g. %20 for a space).

For purposes of this spec, a scheme is any sequence of 2–32 characters beginning with an ASCII letter and followed by any combination of ASCII letters, digits, or the symbols plus (”+”), period (”.”), or hyphen (”-”).

So there must be at least two characters making up the scheme, and not none, and there must be a colon following it.

This is a bit off-topic for this issue, though.

[pickfire]

@kivikakk Okay, I think that's not an issue here. But I would really like it to accept // without a scheme, web browser allows that.

[kivikakk]

@pickfire I think this would require complicating the spec quite a bit; e.g. we don't allow many other things in an autolink that a web browser would allow; see some of the examples from http://spec.commonmark.org/0.26/#example-567 and below.

It'd complicate the spec and parsing a fair bit — differentiating <//an-autolink> from </close-tag> may be non-trivial, for instance — so you're probably better off just using the […](…) format here.