我为什么还在用 Emacs 写博客?这是一个看似简单却包含技术信念与生活方式选择的问题。许多人在搭建博客时会选择轻量级的静态站点生成器,比如 Hugo、Jekyll 或 Hexo,它们启动快、生态丰富、模板灵活。而我从最初的好奇到现在的坚持,关键在于 Emacs 所提供的整体写作与可重复计算体验,尤其是 Org mode 与 Org Babel 带来的无缝整合。 Emacs 并不是最快的工具,也不是最时髦的选择,但它把写作、代码、数据与出版流程串成一个不可分割的工作流。Org mode 允许我在同一文件中既写正文,又嵌入可执行的代码块,导出为 HTML 或其他格式时可以自动运行这些代码、插入表格与图像。这种方式改变了写作的本质:稿件不再只是文本,而是包含计算步骤与可追溯过程的活文档。
对于需要同时处理数据、绘图和叙述的技术博客与研究笔记,Org Babel 的价值难以用简单的静态生成工具替代。 很多人会问:理解整个导出流程是否必要?答案取决于你愿意承受多少抽象层次。Org 的导出系统确实复杂,ox-html、ox-publish 与 org-element 等 Lisp 文件构成了一个庞大的生态,总行数远超许多独立静态站点生成器的代码量。我的真心话是,我并不完全理解 org-publish-current-file 在内部做了什么,但我乐于珍惜 Emacs 提供的实用性。对我而言,掌握高层工作流比深究底层实现更有价值:写作时能专注于内容,发布时依赖成熟的导出机制。若有一天某个步骤出错,我会追踪错误,但平常并不需要每天都理解每一行 Lisp。
Emacs 的一个决定性优势是可重复性。写博客时经常会嵌入数据可视化、统计结果或实验输出,手动更新图片或表格容易出错。Org Babel 可以在导出时执行代码并将输出嵌入文档,这意味着当数据或代码改变时,导出得到的最终网页会自动更新。对于希望将数据分析与叙述合并的作者来说,这是一种能显著提高信任感与效率的工作方式。可重复的输出还方便回溯与审阅,任何读者或未来的自己都能重现关键计算过程。 另一个经常被忽视的优点是会话管理。
Org Babel 支持跨代码块共享会话变量,允许在一个长期交互的会话中逐步构建分析过程。与单独运行脚本相比,这种方式能更自然地记录探索过程:先运行一个数据清洗块,再在后续块中引用已创建的数据对象,不用反复导入或重新执行整段代码。对使用 R 或 Python 进行数据分析的作者而言,这种互动体验既熟悉又高效。 使用 Emacs 并不意味着自动排除其他工具。事实上,我在写作与发布时常常会混合工具链。Org 文档可以导出为 Markdown,再交由像 Hugo 这样的静态站点框架处理页面与模板;也可以直接导出为 HTML 并通过 rsync 或 Git 部署到静态托管服务。
对有些人有吸引力的替代方案如 RMarkdown,提供了在 Markdown 世界中类似的代码执行能力,并且与 Hugo 集成紧密。RMarkdown 的生态对 R 用户非常友好,配合 VS Code 或 RStudio 也能获得优秀体验。尽管如此,我习惯了 Emacs 的编辑体验、广泛的快捷键体系以及 Org mode 的语义标记,这些都是短期内难以割舍的生产力资产。 承认 Emacs 的劣势是保持现实的开始。Emacs 的学习曲线陡峭,配置常常需要阅读大量文档与 Emacs Lisp。导出流程有时会出现不可预期的断裂,例如某个代码块的依赖未正确加载、图片路径配置不当或导出模板与 CSS 冲突。
解决这些问题需要耐心,有时也需要回退到手工处理图片或局部脚本。此外,在团队协作场景中,非 Emacs 用户可能不熟悉 Org 文件,这会带来共享与合并的摩擦。面对这些现实,权衡便显得尤为重要:如果写作需求高度依赖可执行代码、可重复结果与细粒度交互,Emacs 是合适的选择;如果目标是快速启动、跨团队标准化与模板驱动,轻量级静态站点工具或托管平台可能更合适。 对个人博客作者来说,成本与收益会随时间动态变化。我曾梦想写一个两千行的自制静态站生成器,完全控制所有细节。实践告诉我,复刻 Org Babel 的功能不仅仅是工程量的问题,还涉及对会话管理、代码执行与跨语言支持的深层理解。
那样的工程会从周末项目变成数月的投入,回报却未必与投入成正比。与其重造轮子,更现实的策略是扩展已有工具或用脚本补足短板。例如编写小型 Emacs 函数来统一导出流程、用 Makefile 自动化发布步骤,或将复杂的数据处理封装到可重用的 R 脚本中并在 Org 中以最小接口调用。这些做法保留了 Emacs 的核心优势,同时降低长期维护成本。 在实践层面,我的工作流包含几个关键环节。首先,以 Org 文件为主要创作载体,文本、代码与元信息集中管理。
其次,使用 Babel 的标签与参数控制代码执行,例如缓存长时间运行的块或指定图像生成路径。再次,利用 Emacs 的版本控制集成与 Git 管理草稿与发布历史,确保可以回滚或比较不同版本的输出。最终通过简单的发布脚本触发导出与同步。这样的流程既不完美,也并非纯粹的黑箱,但在日常写作中它足够稳定并支持可重复的结果。 我也建议对初学者做出几条经验性的提醒。不要尝试一次性掌握所有 Org 的高级特性,从最常用的代码块、导出选项和图片插入入手。
学会利用缓存与会话可以显著节省调试与导出时间。为图片与表格建立统一命名与存储规范,避免导出时路径混乱。定期测试导出流程,尤其是在更改模板或升级 Emacs/Org 版本后。最后,适度借助社区资源与示例配置,Emacs 社区中有大量成熟的写作配置可供参考。 放眼未来,写作工具的选择既是技术决策也是生活方式选择。Emacs 与 Org mode 的组合并非适合每个人,但它提供了一种将写作视为可重复研究的可能性。
它把文本创作与计算过程放在同一语境中,降低了从草稿到最终发布之间的认知断层。对于习惯在编辑器中开展深度工作、重视可追溯性与可重复性的作者,这种体验难以用仅面向发布的工具完全替代。 总结我的立场:我继续用 Emacs 写博客,不是因为它无懈可击,而是因为它在满足我对可重复性、交互式分析与长文本结构化方面具有独特的优势。它要求我在配置与维护上投入时间,也会在某些时候让我对复杂性心生厌倦,但当我看到在同一文件里既有清晰的论据又伴随可重现的图表时,那种满足感会重复证实我的选择。对任何在写作与数据之间寻找桥梁的作者而言,Emacs 与 Org Babel 值得认真评估。 。
