及时的文档转换的库, 类似 pandoc

[chaoxu]

我是需要常常写文章和笔记的人。我总是存在于两个模式之中。写作和编辑。

这两个系统的操作模式非常不同。

• 写作模式：几乎所有的时间是在写东西。目标是快速的将自己脑子里的东西变成（接近）自己想要的输出。
• 编辑模式：文章几乎写好，要开始对文章做一些修改。这个时候，看输出的结果。在输出的结果里找到了问题，修改输入，再看输出结果。

作为一个编辑的例子。我用 LaTeX 写好了东西，改文章的时候一般是打印出 pdf ，仔细的看。找到了所有有问题的地方，再回到代码那里一次性的做改动。每一个改动平均要花 20 秒的时间来找到它在源代码的哪个地方。如果有所以 60 处小改动，20 分钟就花在了纯粹的寻找上。

有以下两个思考：

• 应该根据人本身的写作方式创建一个最适合自己的输入形式。比如，用 markdown 但是从来不需要写代码的人，用 indent 创建的代码 block 这个功能完全没有用。比如让 indent 有其他功能，如 blockquote 。
• 编辑模式中，发现了问题可以快速的修改。也就是能在输出的地方找到错误，可以把自己送到对应的输入的地方。

所以一个高效文档修改的系统应该存在 3 个不同的部分，并且可以互相对应。也就是以下 3 个层之间的变换。

• 输入层，这个是自己的输入语言。可以想象是 markdown 。我们应该对输入的语言创建一个 AST 。
• 逻辑层，这个是我们自己定义出来的一个 AST 。可以表示我们应该想要表示的所有语义。
• 输出层，根据逻辑层 AST 创建输出。可以想象是 HTML 。

研究过 Pandoc 这个任意 document 之间的转换器的人会发现这就是 pandoc 的工作形式。Reader 读取输入 X(比如 markdown)到 Pandoc AST, Writer 将 Pandoc AST 写成 Y(如 html, latex 源码)。

的确不少人用这样的系统来做简单的写作。自己写 markdown ，pandoc 编译了就输出 html 显示在另一边。比如我的博客就是这样了。(例子)。这个系统用来写作很不错，但是用来编辑就要累不少，因为输出层和输入层之间的转换有很大的 friction 。博客的好处是东西一般不会很长，但写文章的话那可是随随便便几十页纸（例子）。

如果想要做的再好一点，应该是类似 Typora 那样。输入和输出部分几乎是放在一起的。也就是除了光标所在的地方，几乎都是输出的样式。Typora 的粒度过细。以前的版本改比较大的数学公式的时候各种跳来跳去痛苦极了，不知道现在如何。改为每一行的粒度可能不错。也就是光标所在的行，只显示输入层，光标不在的行都是输出层。或者让用户可以自己选择粒度。

要满足这样的系统，上面三层应该局部对应。这三个不同的树之间，两两应该有简单的局部的双向转换。 这样的系统做好了，vditor这样的工具就会比较容易制造出来，并且可以支持任何输入和输出方式。

[hamsterbase]

编程语言也是一样的思路。llvm 分为三层， 前端 + 优化器 + 后端。

前端负责把语言转化为中间语言，优化器负责优化性能，后端负责把中间语言转化为机器码。

[hamsterbase]

1. 编辑器的 ast
2. 通用的 rich text ast
3. html markdown word ast


其实社区可以开发一个通用的 rich
text ast 。以后开发编辑器，只需实现编辑器 ast - rich text ast 的相互转换就行了。

[chaoxu]

@hamsterbase

嗯。Pandoc 的 AST 实际上就满够用的。有的地方需要增加点自定义的 extension 也可以。

需要能跑在浏览器里就是了。