之前一开始还是很喜欢 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 的痛点有以下几个:
- 解释渲染规范的不统一
- 基于空格的表现形式很容易误解
- 多样化的表现形式(对同一种效果有多种写法)
最后,本来是想写一个解释器,后来想到能不能自己实现一个语言的定义,然后通过生成 AST,方便进行各种语言的互转。
这就是之后需要着力思考的问题了。