之前一开始还是很喜欢 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，方便进行各种语言的互转。
这就是之后需要着力思考的问题了。