关于 blockquote 的嵌套处理 #5
Comments
|
经测试，GitHub 的列表嵌套最大深度为 10。 m('+ '.repeat(30) + ' list')GitHub 编辑器得出的结果<ul>
<li>
<ul>
<li>
<ul>
<li>
<ul>
<li>
<ul>
<li>
<ul>
<li>
<ul>
<li>
<ul>
<li>
<ul>
<li>
<ul>
<li>
</li><li>
</li><li>
</li><li>
</li><li>
</li><li>
</li><li>
</li><li>
</li><li>
</li><li>
</li><li>
</li><li>
</li><li>
</li><li>
</li><li>
</li><li>
</li><li>
</li><li>
</li><li>
</li><li>
</li><li>list</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
</ul> |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
markdown语法支持blockquote的嵌套，于是有一段丧心病狂的测试代码出现了：而在
zmd的处理的时候，会出现这样的错误：多么熟悉的错误提示：
Maximum call stack size exceeded，便就是传说中的爆栈。上面的代码是这个：
... while (this.next().type !== 'blockquote_close') { body += this.compile() } ...查看代码
查看 GitHub 编辑器中的结果
这段文本如果在 GitHub 的编辑器中，得出的结果长这样：
可以看到，从 256 行开始做了截断操作。后面的内容给忽略掉了。
zmd的核心参考项目marked曾经想过试图在不截断的情况下处理这个问题，但是很遗憾，最终未能成功。截至本 issue 发布之日，marked已经回滚该操作。marked采用的方式是预判下一个直接跟随的词法分析结果是不是blockquote_start，如果是，则挂起一个操作，继续往下，然后在收尾的一并处理blockquote_end。然而却出现了不能正确渲染
> 1\n> > 2这样的文本，本人曾经调试过，问题出在this.next环节，词法分析结果已经走完，但仍然会因为前面挂起了blockquote_start，收尾的时候判断出了点问题，导致操作失败。所以，该如何处理这个问题，像 GitHub 一样直接做一个截断如何？还是放任该问题不管不顾？毕竟，实际操作中没有人会去搞一个这么大的嵌套。实测 5000 的时候勉强还是可以解决。
说到嵌套，相信列表也会面临同样的问题。
The text was updated successfully, but these errors were encountered: