-
-
Notifications
You must be signed in to change notification settings - Fork 320
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
link reference definition versus other elements #688
Comments
Another pair of examples that could go after example B, interrupting the url instead of the link title: Example B2 (valid link ref def):
Example B3 (an h1 with no link reference definitions):
|
I think this is a good suggestion. |
Sure, will send one. |
Other blocks can interrupt a link reference definition, and link reference definitions can have continuation text that is not fully prefixed, following the rules of paragraph continuation text. Document both these facts and give examples. Fixes commonmark#688.
Other blocks can interrupt a link reference definition, and link reference definitions can have continuation text that is not fully prefixed, following the rules of paragraph continuation text. Document both these facts and give examples. Fixes commonmark#688.
Other blocks can interrupt a link reference definition, and link reference definitions can have continuation text that is not fully prefixed, following the rules of paragraph continuation text. Document both these facts and give examples. Fixes commonmark#688.
PR #689. |
I can't find the relevant issue or forum post, but @jgm has confirmed previously that this behavior is an artifact of the parser implementation: for efficiency or simplicity it first parses out paragraphs and later parses Link Ref Defs from the top of the paragraphs. In other words, it's an accident and not how LRDs are supposed to behave. Lazy continuation is only for paragraphs. I'm guessing the interruption issues have the same cause, i.e. LRDs are inheriting paragraph rules around interruption as an artifact of the parser implementation... though I don't have the time to examine that right now. @jgm Have you changed your mind? I have an implementation (not yet released) that does not take this shortcut and conforms to the spec as-is, so it's certainly doable. |
Happy to remove or adjust the continuation text examples according to whatever the consensus is. |
The 0.30 spec does not mention that link reference definitions can be interrupted by other elements.
It does say:
and then it gives the example (215):
This is, as the text said, "not followed by a blank line", because the link reference definition has unambiguously ended before the
bar
. However, there are other cases where a link reference definition could arguably be in progress but the block structure interrupts it.I suggest adding replacing examples 215-216 with something like:
The text of a link reference definition can be interrupted by any block element that can interrupt a paragraph:
Example A
Example B
Example C
Example D
Example E
Example F (== example 216)
Example G
Example H
Example I (== example 215)
Example A is a link reference definition with an ordinary multiline title.
Examples B, C, and D do not have valid link titles: the title text is interrupted by block-level structure. Whether the overall link reference definition remains valid depends on whether the title started on a separate line.
Example E is a valid link title: indented code blocks cannot interrupt paragraphs, so they also cannot interrupt link titles.
Examples F, G, and H are valid link reference definitions: they are completed, leaving no paragraph text for the
===
to use to create a setext heading.Example I also completes a valid link reference definition, leaving the unquoted
bar
for use in the setext heading.Along the same lines, after example 218, I suggest adding something like:
The text of a link reference definition can be continued using the same rules as for paragraph continuation lines:
Example J
This is all a bit roundabout and it would seem easier to say something like "Link reference definitions are removed from the start of each paragraph's initial text as the paragraph is accumulated. If no text remains, then there is no paragraph left behind." But that's probably too operational for the spirit of the spec.
The text was updated successfully, but these errors were encountered: