吐槽 Markdown 的设计

之前一开始还是很喜欢 Markdown 的,相对来说比较的简单,从 office word 转到 mardown 的一段时间,适应了之后,写文章的速度就有了很大的提升。

但是,自从开始了编写 markdown-parser,一个 markdown 的解释器,就发现,markdown 的规范都是扯淡,并没有一个很好的官方规范性的文档和转义规范。

比如无顺序的列表,-,+,* 都可以作为前置表达符。但是有的解释器,对*号并不支持。关于引用部分就更加的随机了。如下的一段文章

> Hello World
\```
Hello World
\``` 

有将代码块放入上述引用块的,也有分开的。对于这种有歧义的语义,似乎作者并没有给出一个正确的渲染结果。其次,对于列表嵌套引用块,很多解释器都选择了无视。而对于 html 标签的支持,有的解释器支持,而对于 github ,则会选择过滤掉 html 标签。

所以总的来说,markdown 是一个松规范的写作格式。可以进行简单的文字编辑,但是如果要进行深入的修改,重格式的调整,还是建议使用 MS 的 office 套件。

因为为什么要重新写一个解释器,因为很大的程度上,我会使用 hexo,github 进行文章的保存和简单的 readme 文档编写,然后本地的 markdown 预览和解析则是会产生一部分错误的格式。比如本地预览 ok,但是发布到 hexo 上的时候,就会遇到各种的格式错误。

所以我需要一个尽量能和以上解析行为保持一致的解释器。调研了几个,最后发现只有 rtfd/CommonMark-py 符合最初的需求。但是从 issue 上看,支持 table 的日程相当的靠后。而且对于 github favourite markdown 还是有相当的差距。

最终在没有找到合适替代品的情况下,只好自己开始了编写的过程。在解释 tab 语义的时候,确实遇到了麻烦,看了无数个解释器,各有各的表现形式,很是无奈。也是表达对这种松散的格式的不满。缺乏一个严谨的态度。但换句话说,也正是这种随意,才让 markdown 火起来吧。

非常欣赏 go 语言的设计思路,做一件事,只有一种实现方式。这样方便代码的 review 也方便排查错误。这也是 go 是我最看好的一个原因。有着较为完善的配套设施,并且有这非常工业化的设计思路。

总的来说,Markdown 的痛点有以下几个:

  1. 解释渲染规范的不统一
  2. 基于空格的表现形式很容易误解
  3. 多样化的表现形式(对同一种效果有多种写法)

最后,本来是想写一个解释器,后来想到能不能自己实现一个语言的定义,然后通过生成 AST,方便进行各种语言的互转。

这就是之后需要着力思考的问题了。

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.