Skip to content
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

Open
rsc opened this issue Sep 4, 2021 · 7 comments · May be fixed by #689
Open

link reference definition versus other elements #688

rsc opened this issue Sep 4, 2021 · 7 comments · May be fixed by #689

Comments

@rsc
Copy link

rsc commented Sep 4, 2021

The 0.30 spec does not mention that link reference definitions can be interrupted by other elements.
It does say:

However, it can directly follow other block elements, such as headings and thematic breaks, and it need not be followed by a blank line.

and then it gives the example (215):

[foo]: /url
bar
===
[foo]

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

[foo]: /url '
bar
'

[foo]

Example B

[foo]: /url '
# h1
'

[foo]

Example C

[foo]: /url '
> quote
'

[foo]

Example D

[foo]: /url
'
- list item
'

[foo]

Example E

[foo]: /url '
        not a code block
'

[foo]

Example F (== example 216)

[foo]: /url
===
[foo]

Example G

[foo]: /url 'bar'
===
[foo]

Example H

[foo]: /url
'bar'
===
[foo]

Example I (== example 215)

[foo]: /url
bar
===
[foo]

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

> [foo]: /url '
hello
'
> [foo]

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.

@rsc
Copy link
Author

rsc commented Sep 4, 2021

Another pair of examples that could go after example B, interrupting the url instead of the link title:

Example B2 (valid link ref def):

[foo]: # 
[foo]

Example B3 (an h1 with no link reference definitions):

[foo]:
# 
[foo]

@jgm
Copy link
Member

jgm commented Sep 4, 2021

I think this is a good suggestion.
Would you like to do a PR?

@rsc
Copy link
Author

rsc commented Sep 4, 2021

Sure, will send one.

rsc added a commit to rsc/commonmark-spec that referenced this issue Sep 4, 2021
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.
rsc added a commit to rsc/commonmark-spec that referenced this issue Sep 4, 2021
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.
rsc added a commit to rsc/commonmark-spec that referenced this issue Sep 4, 2021
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.
@rsc
Copy link
Author

rsc commented Sep 4, 2021

PR #689.

@vassudanagunta
Copy link

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.

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.

@vassudanagunta
Copy link

Relevant OPEN issues that comment on this: #605, #574 and #622. Possibly also relevant: #583

@rsc
Copy link
Author

rsc commented Sep 7, 2021

Happy to remove or adjust the continuation text examples according to whatever the consensus is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants