Org Mode与Markdown，流行度差异探因

欧洲

Org-mode 与 Emacs 的结合过于紧密，存在不少棘手的问题。尽管我欣赏 Emacs，但不得不承认，Org-mode 和 Emacs Lisp 都存在一些显著的设计缺陷，这些问题影响了整体的使用体验。Org-mode的设计者显然只熟悉英文或欧洲语言，未考虑其他语言特性，请看以下代码。你希望世界两字加粗突出，但结果显示并非如此。

这是什么情况？其实，你需要在每个词之间加上空格，这样就能得到正确的格式了。

这个问题的根源在于 org-mode 的设计者假定用户使用以空格分隔单词的语言，如英语。然而，中文并不符合这种语言特性，因此出现了不适应的情况。为解决这个问题，emacs-china论坛有篇长帖讨论多种方案。我们拥有这些丰富的资源。这些方案各有千秋，也各有缺陷。但别忘了，有些用户使用其他工具来处理 org-mode。例如，我偏爱用 pandoc。Pandoc 自己开发了一个 org-mode 解析器，同样面临这个问题的影响。无论选择哪种工具，都需谨慎权衡其利弊。我确实是Haskell用户，也懂如何修改Pandoc的源代码。但我不禁思考，为何我要花费如此多时间在这上面？提到 org-babel，我就一肚子火。它的默认行为居然是阻塞的！也就是说，你写了个死循环，它就卡在那里不动了。恭喜你，你的 Emacs 在执行第二块代码后崩溃了！哈哈，Org-Babel 的体验真是太棒了。这种顺畅的感觉让人忍不住笑出声。幸好，我们有 ob-async。然而，安装了 ob-async 并不代表能顺利进行文学编程。很快，你会遇到新的问题。咦，为何出现错误提示？

这个错误是因为 ghci 不支持直接多行输入，需使用 :{ 和 :} 包围多行代码才能正确执行。我曾修改 ob-haskell.el 的源码以解决该问题，但类似的问题仍然存在。对于那些双向链接、日程管理和其它花哨的功能，我其实并不怎么使用。我真正需要的只是一个能写文档的标记语言，以及进行简单的文学编程。对我来说，即使使用 Emacs，org-mode 也没有太多吸引力。我这样的用户更注重简洁和实用性，而不是复杂的功能堆砌。