The commonmark renderer's escaping strategy is very aggresive
维护者通常 2 天内回复
还没有人认领这个 Issue。
评估
调研方向
从 commonmark renderer 的转义逻辑开始，运行 make roundtrip_test 和 roundtrip.sh，并使用 ! case 和 Example 533 作为回归检查点。将 build/src/cmark 的输出与预期的 HTML 进行比较，然后为文本和链接渲染定义更窄的转义策略；完成的标准是普通标点不会被不必要地转义，同时链接和图片的 round trip 仍然通过。
由索引模型根据 Issue 内容生成。
描述
I am currently evaluating the usefulness of cmark as an indentation / formatting tool.
The width parameter makes cmark already quite suitable, though I would remove all soft breaks and normalize before rendering in case HARDBREAKS wasn't passed, this would avoid such cases:
A very long line that the user manually broke because it was really getting
too long
rendering to
A very long line that the user manually broke because it was
really getting
too long
Anyway, my real issue here is that a lot of characters are preemptively escaped, even though they could actually pass through unescaped. I understand that the initial intent was (and rightly so) "better safe than sorry", but I think we should now look back at how to be more clever wrt these characters, starting with the most likely to be used in a common sentence.
Case in point: !
Currently given that input:
Hello amigo!
we have this output when running cat hello.md | ./build/src/cmark -t commonmark
Hello amigo\!
This was introduced by efeb7093a3e6a96019b0805fc630a7aa4c31481b. The specific reason for this is not stated in the commit message, but when resetting cmark to the previous commit, and running make roundtrip_test , it becomes clear:
Example 533 (lines 7317-7323) Images
\![foo]
[foo]: /url "title"
--- expected HTML
+++ actual HTML
@@ -1 +1 @@
-<p>!<a href="/url" title="title">foo</a></p>
+<p><img src="/url" alt="foo" title="title" /></p>
589 passed, 1 failed, 0 errored, 0 skipped
I haven't investigated why, but I suspect the roundtrip tests are broken in current master,
as even when deactivating all escaping in the renderer, the roundtrip_executable test still happily
reports success. The issue can be reproduced with current master by "reverting" this
commit (might conflict, edited the case out) and running rountrip.sh manually.
Furthermore, some code was obsoleted in this commit (but still lives in the current HEAD):
needs_escaping == [...] c == '!' || [...] || (c == '!' && nextc == '[')
This should be removed, but helps us understand the issue at hand, and the shortcomings of the current strategy:
The previous code tried to determine whether ! should be escaped by looking at the next character in the literal stream it was parsed from, bounded by its containing block limits. However here, the next character is NULL, and the issue was triggered by the next character we output, which was '['.
The fix that was introduced for this escaped all ! , end of story. However I think a more appropriate fix would be to escape it "retroactively": the only case I'm aware of where '!' can have a semantic meaning is when it is followed by '[', as such we should, in the case where the renderer ends up outputting it on its own (case CMARK_NODE_LINK), be able to verify that the previous character that was output was a "!", and only then insert an escape character in the strbuf. We should obviously make sure to escape it only if it was contained in a TEXT node, but that shouldn't be too hard.
I haven't studied the code further yet, because I thought this was the most glaring issue, however I also strongly dislike the underscore escaping, because it requires function_names to be wrapped in a code inline in order to escape escaping.
We should determine the conditions under which most if not all of these characters need to be escaped, and try to determine if we can come up with a better strategy, in order to make cmark more usable as a source-to-source tool, I hope you folks can help me study each case :)
- 主要语言
- C
- 星标
- 2k
- 派生
- 703
- 平均合并
- 2 天 10 小时
- 30 天内合并 PR
- 8
环境准备
这个项目没有提供开发容器、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 于 46 天前认领。 未关闭
难度 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 天内回复
-
难度 4/5 3-5 天 新手友好度 52/100
commonmark/cmark#626 · 4 条评论 ·
维护者通常 2 天内回复
-
难度 4/5 3-5 天 新手友好度 35/100
commonmark/cmark#624 ·
维护者通常 2 天内回复
-
Single-space blank line evicts a list-item continuation可能重新可做 关联的 PR 已关闭且未合并。 未关闭
难度 3/5 1-2 天 新手友好度 65/100
commonmark/cmark#618 ·
维护者通常 2 天内回复
相似的 Issue
-
vim.filetype.match() prefixes a URL buffer name with the cwd before passing it to filetype functions未关闭
难度 2/5 1-3 小时 新手友好度 73/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
COVESA/dlt-daemon#925 · 1 个 reaction ·
-
stream_curl: retry_count never resets after a successful reconnect, so long sequential streams die after 5 drops可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 2/5 1-3 小时 新手友好度 70/100
mpv-player/mpv#18728 ·
维护者通常 1 天内回复
-
followup Prio 📌
难度 2/5 1-3 小时 新手友好度 66/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
cyrusimap/cyrus-imapd#6640 ·
维护者通常 2 天内回复