Bug in lazy blockquote continuation (or corresponding spec is wrong, whichever)
维护者通常 2 天内回复
还没有人认领这个 Issue。
评估
调研方向
首先使用 cmark 命令重现这两个示例，并将其 block quote 和列表解析与链接的 CommonMark 0.27 规范进行比较。确定是实现还是规范不正确，然后添加一个回归用例并记录已解决的行为。
由索引模型根据 Issue 内容生成。
描述
Current spec says:
If a string of lines Ls constitute a block
quote with contents Bs, then the result of deleting
the initial [block quote marker] from one or
more lines in which the next [non-whitespace character] after the [block
quote marker] is [paragraph continuation
text] is a block quote with Bs as its content.
http://spec.commonmark.org/0.27/#block-quotes
This spec is clear, and explicit. I see no ambiguity. Now consider this blockquote:
> This is _a_ paragraph continuation text
> 2. because the line starts with `2`, not `1`.
This blockquote is valid, and satisfies the "If a string of lines Ls constitute a block quote with contents Bs" condition. So according to the spec, we can delete the leading >. By doing so we get this:
> This is _a_ paragraph continuation text
2. because the line starts with `2`, not `1`.
This blockquote, according to the spec, must be identical to the former one. However cmark does not agree.
% cmark <<'EOS'
> This is _a_ paragraph continuation text
> 2. because the line starts with `2`, not `1`.
EOS
<blockquote>
<p>This is <em>a</em> paragraph continuation text
2. because the line starts with <code>2</code>, not <code>1</code>.</p>
</blockquote>
% cmark <<'EOS'
> This is _a_ paragraph continuation text
2. because the line starts with `2`, not `1`.
EOS
<blockquote>
<p>This is <em>a</em> paragraph continuation text</p>
</blockquote>
<ol start="2">
<li>because the line starts with <code>2</code>, not <code>1</code>.</li>
</ol>
%
Is it intentional?
- 主要语言
- C
- 星标
- 2k
- 派生
- 711
- 平均合并
- 3 天 13 小时
- 30 天内合并 PR
- 10
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
commonmark/cmark 的其他 Issue
-
Incorrect `parser->offset` advancement for closing fenced code blocks in `parse_code_block_prefix`可能已有人在做 @cpruijsen 于 54 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 76/100
commonmark/cmark#590 · 3 条评论 ·
维护者通常 2 天内回复
-
API documentation is missing an explanation of CMARK_NODE_CUSTOM_BLOCK and CMARK_NODE_CUSTOM_INLINE未关闭
难度 2/5 1-3 小时 新手友好度 68/100
commonmark/cmark#441 · 2 条评论 ·
维护者通常 2 天内回复
-
难度 3/5 1-2 天 新手友好度 70/100
commonmark/cmark#656 · 1 个 reaction ·
维护者通常 2 天内回复
-
难度 4/5 3-5 天 新手友好度 52/100
commonmark/cmark#626 · 4 条评论 ·
维护者通常 2 天内回复
-
难度 4/5 3-5 天 新手友好度 35/100
commonmark/cmark#624 ·
维护者通常 2 天内回复
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 75/100
micropython/micropython#19906 ·
维护者通常 1 天内回复
-
QOI: QOI_OP_RUN does not update the previously seen pixels, corrupting qoi_test_images/edgecase.qoi可能已有人在做 @manit2004 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
python-pillow/Pillow#10452 · 4 条评论 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 75/100
维护者通常 10 天内回复
-
难度 2/5 1-3 小时 新手友好度 77/100
JPHutchins/dynamic-call-tree-resolution#349 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复