Block Quotes, Laziness, and Link Reference Definitions

2

I don’t know how Dingus implements this.

But many implementations right now (including Cmark as the reference one) parse link reference definitions specially only later after the normal block analysis. I.e. they parse them initially as a part of paragraphs and only later they rip them off from beginnings of the paragraphs (and paragraphs becoming empty are discarded completely, so that <p></p> is not emited).

It makes the implementation much easier in several aspects:

  1. It’s easier because you cannot decide whether you encounter the link ref. def. just from its first line. The link ref. def. can occupy many consecutive lines. And some look ahead of an arbitrary length in the block pass could be dangerous in order to prevent a O(n^2) behavior.

  2. You can share a lot of code with inline analysis (recognition of many link components like destination or title) because you already have the same data structures prepared and initialized. I.e. it makes a smaller space for other bugs (like inconsistency in recognition of link destination or titles between inline links and the reference definitions).

  3. It solves some complicated cases. Especially imagine multi-line link reference definitions inside a container block (a list item or a quote block). You don’t want the link reference definition parser to be confused by the marks or indentations which belongs to the enclosing container syntax. The output of the block analysis does this for you for free.

    For example:

    >>> 1. [link. ref. def inside a list item, nested in a block quote]:
>>>     /with_a_destination
>>>     `And with a multiline
>>>     title`

Strictly speaking, I agree with you, as of the current spec. wording, this approach is likely incorrect in respect to some corner cases like the one you have come up with. From the point of view of the specification the link. ref. def. is just a normal block, and the spec never allows the lazy continuation line for anything but a paragraph.

On the other hand, intuitively, imho it’s good that the lazy continuation can work here too. It makes a good sense to me. Paragraphs may follow the definition without any blank line. And it sounds funny to me to require that e.g. a lazy continuation lines begins to work only later so you may need to write this:

> [foo]: 
> /destination
> `some multiline
> title`
> But now a paragraph following the link. ref. def. can
use a lazy continuation line. Strange.

@jgm But of course, the discrepancy between the specification and the implementation should be fixed.

2 Likes