Tecosaur 等人重写 Org mode 的 LaTeX 预览功能

简而言之：Org mode 中的 LaTeX 现在渲染得又快又漂亮。安装 Org mode 的开发分支即可使用。

十多年来，我一直对 Emacs——尤其是 Org mode——中 LaTeX 预览的不足颇有怨言。于是，Tecosaur 和我决定迈出这一步，从零开始重写这个功能。最终成果是一个 LaTeX 数学预览系统，它能提供接近所见即所得的反馈，同时保留了我们在 Emacs 环境中所期望的特性：文本优先、可扩展、可组合。

代码量不大，但涉及许多组件，并与 Emacs 的多个角落产生交互。既然这个功能已经成为 Org mode 的一部分，我想借此机会从头记录它的工作原理，并以此为契机解释 Emacs 事件循环及其非官方包 API 的相关方面。Emacs 实际上并没有“包 API”，因为你构建 Emacs 包所用的元素与 Emacs 本身完全相同。

本文并非对所有炫酷新功能的详尽演示，尽管文中穿插了几段视频。它也不是用户手册（orgmode.org 上尚未更新）或教程（参见 Tecosaur 的 This Month in Org 文章）。相反，它旨在概述该库的目标和设计，同时解释 Emacs API 的相关方面，并提供编写你自己功能的技巧。如果你对以下内容感兴趣，本文适合你：

什么是 org-latex-preview？

这是 Org mode 附带的一个功能，用于在 Emacs 缓冲区中将 LaTeX 数学片段预览为图像。Org mode 中 LaTeX 片段和环境的内容会被替换为渲染后的图像。

这个功能已经存在了几十年，但我认为其形式几乎不可用；这次重写 overhaul 了代码库，并增加了许多提升使用体验的功能。有一段 13 分钟的演示可以让你很好地了解 Org mode 的新能力：

本文其余部分主要讲述其工作原理，并简要说明原因。因此，它具有“分形”级别的细节。信息旨在：

为此，许多细节被藏在如下所示的块中。你可以安全地忽略它们，只看顶层标题、图像和视频演示。

这样的块描述代码某些方面的具体实现。这 probably 只有在你打算深入研究代码本身，或者想编写类似包时才有意思。

这样的块是对 Emacs API 方面的补充说明，包括一些零散的代码片段。

这样的块描述与 LaTeX 预览生成相关的其他 Org 功能。

这样的块描述与此过程相关的 CLI 命令或其输出。

LaTeX 的设计初衷并非最小化延迟。即使只改动一个字符，也必须启动多个新进程，这为实时反馈的可能性设定了硬性上限。相比之下，为像 Typst 这样为现代计算机设计的系统实现等效的预览功能则轻而易举。

此外，尽管 Org mode 很流行，但它在标记语言领域只是个小角色。愿意用 Org mode 来写 LaTeX 的 Org 和 LaTeX 用户比例就更小了。而且，尽管 Org 试图与 LaTeX 良好集成，但在 Org 和 LaTeX 语法的混杂中摸索，会在分别学习这两种标记语言之外增加额外的学习曲线。

但它也有几个优势。

首先，LaTeX 无处不在，而 Org mode 是比原始 LaTeX 方便得多的写作格式。视觉噪音显著更少（想想 Markdown 与 HTML 的对比），而且 Org 提供了逐字添加 LaTeX 的逃生通道。Org 简单的文本搬移、任务进度监控和代码块执行接口，使得最终的 LaTeX 文档可以轻松地以 Org 文件起步。由于 Emacs 中的一切都可以相互组合，你（比如）快速输入 LaTeX 的系统可以无缝迁移到 Org mode。

其次，Org 作为发布工具的通用性意味着，更好的 LaTeX 支持所带来的某些好处也会转移到其他格式，比如 HTML 或 ODT 导出中的公式。

有大量基于 Org mode 构建的应用受益于 LaTeX 数学输入，例如 Org Roam 和 Org Noter。对这些应用而言，将 Org 文档转换为 LaTeX 并非目标，因为它们主要不是发布工具：它们作为私人数字档案长期存在，更好的 LaTeX 支持是对用户表达能力的额外加成。

编辑 LaTeX 片段时的实时反馈是对用户体验的质的提升。我在开始开发 org-latex-preview 时并未意识到这一点，但现在没有它我就不想写 LaTeX 了。

令我困惑的是，网页版 LaTeX 编辑器（Overleaf 等）居然不默认提供这个功能，尤其是它们的目标用户是 LaTeX 新手。

最后，我们可以把 Org mode 排除在外：org-latex-preview 从技术上讲可以在 Emacs 的任何地方、任何 major-mode 中工作。只是目前还没做到（见下文）。

但也许最贴切的原因是，Emacs 用户从不回避舒适地安顿在狭小、拥挤且隔热不良的角落里。这是理所当然的！

Emacs 用户对其频繁的无响应深有体会。你离导致 Emacs 阻塞或卡顿，永远只差一个 minor-mode 或 mode line 指示器。虽然为你发起的操作等待一秒钟不算什么大事，但无响应常常表现为短暂的随机冻结，这是不可接受的。但还有更多。除了烦人和不便之外，糟糕的响应性还剥夺了我们一整类用途：实时反馈对交互式应用来说就是一切。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）