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

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

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

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

作为一个编辑的例子。我用 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这样的工具就会比较容易制造出来，并且可以支持任何输入和输出方式。