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

Multi-paragraph list item nested in blockquote #304

Closed
mity opened this issue Jun 14, 2019 · 5 comments
Closed

Multi-paragraph list item nested in blockquote #304

mity opened this issue Jun 14, 2019 · 5 comments

Comments

@mity
Copy link
Contributor

mity commented Jun 14, 2019

Input:

>* foo
>
>  bar

Expected output:

<blockquote>
<ul>
<li>
<p>foo</p>
<p>bar</p>
</li>
</ul>
</blockquote>

Actual output:

<blockquote>
<ul>
<li>foo</li>
</ul>
<p>bar</p>
</blockquote>

Rationale:
See https://spec.commonmark.org/0.29/#example-226. If I prepend every line of it with blockquote mark, it should be the same output, just wrapped in the blockquote, as per https://spec.commonmark.org/0.29/#block-quotes, the "basic case".

(Originally reported at pulldown-cmark/pulldown-cmark#358)

@jgm
Copy link
Member

jgm commented Jun 14, 2019

Is this the same issue as commonmark/commonmark-spec#460 ?

@mity
Copy link
Contributor Author

mity commented Jun 15, 2019

Probably yes, at least the input in this comment seems to be.

EDIT: At the 2nd glance, it's not same. In the referred issue the problem is that when nesting a two-item list inside a block quote, we actually get two one-item lists instead. Here we have one-item list where the item consists of two paragraphs and the parent blockquote breaks that one item into two separate blocks.

In both cases parent container block should not change how we parse its contents. (And that's why I reported here, because imho spec is quite clear in this regard so I considered this just a bug in implementation.)

If we agree on that, then on the implementation level they both may just be multiple manifestations of a single problem, and maybe they may be be different bugs in it. It can even differ in different implementations. So I don't know.

@jgm
Copy link
Member

jgm commented Jun 15, 2019

I think the underlying problem has to do with whether a following space is included in the block quote start marker. Currently a following space is always gobbled, and that can lead to violations of the Principle of Uniformity when (a) the quoted content contains significant indentation, and (b) a space is not uniformly added after >. The linked issue contains some ideas for how to solve this.

@jgm
Copy link
Member

jgm commented Jun 15, 2019

And yes, I believe it is a spec bug. Spec says:

If a string of lines Ls constitute a sequence of blocks Bs, then the result of prepending a block quote marker to the beginning of each line in Ls is a block quote containing Bs.

A block quote marker

consists of 0-3 spaces of initial indent, plus (a) the character > together with a following space, or (b) a single character > not followed by a space.

So in your example the block quote marker on line 1 is just >, while the block quote markers on the following lines are >+SPACE. If we strip these off, then, we get

* foo

 bar

which is a list followed by a paragraph. Thus the implementations are giving you just what the spec says.

@mity
Copy link
Contributor Author

mity commented Jun 17, 2019

I see. I missed the > + space makes the sign here.

Indeed, if I change the input into

> * foo
>
>   bar

(i.e. spaces added after each >), it then works as expected in all the noted implementations.

Sorry for the noise.

@mity mity closed this as completed Jun 17, 2019
QuietMisdreavus pushed a commit to swiftlang/swift-cmark that referenced this issue Jan 24, 2023
Fuzz target for finding quadratic performance issues
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

No branches or pull requests

2 participants