Emacs 31 即将到来：我日常使用的变化

# Emacs 31 即将到来：我已日常使用的那些变化 Karthik Chikmagalur 最近又发表了一篇优秀的 *"Even More Batteries Included with Emacs"*（https://karthinks.com/software/even-more-batteries-included-with-emacs/）文章，深入介绍了 Emacs 目前已经内置的一些鲜为人知的功能。我想写一篇与之镜像的文章。他的文章涵盖的是已经装在箱子里的电池。而我的文章则介绍即将在 Emacs 31 中到达的那些。 Emacs 31 尚未正式发布，但我一直在从 `emacs-31` 分支和 `master` 分支构建它，并且已经日常使用了几个月。每当有新的、有用的功能落地，我就会把它们融入 Emacs Solo（https://github.com/LionyxML/emacs-solo）——我的无外部包的配置中，并加上一个小注释 `; EMACS-31`，以便在正式发布后重新审视它们。 这篇文章就是沿着这些痕迹走一遍。下面提到的每个变化都是我现在配置中正在使用的，并附有说明它的作用以及我保留它的原因。所有这些都不需要任何包。它们要么已经在 `master` 上了，要么即将到来。 免责声明：Emacs 31 仍在开发中（实际上处于预发布阶段），因此在最终发布前，名称和默认值可能会发生变化。以下内容是我在 2026 年中期运行时的状态。如果你不是从 `emacs-31` 分支或 `master` 构建的，请将此视为对即将到来的功能的预览。 ## 开箱即用的 Tree-sitter 如果让我选一个最让我高兴的变化，那就是这个。多年来，要让一个 `*-ts-mode` 跑起来，需要手动填充 `treesit-language-source-alist`，调用 `treesit-install-language-grammar`，并祈祷你的工具链能够编译语法。在 Emacs 31 中，很多这样的繁琐步骤消失了： 将 `treesit-enabled-modes` 设置为 `t` 会切换那些有 tree-sitter 变体的主要模式到 tree-sitter，而 `treesit-auto-install-grammar` 则让 Emacs 在缺少语法时主动提供获取并构建语法的选项，而不是直接报错。这就好比 `treesit-auto` 包的体验，只不过现在核心完成了这项工作。 这种连锁反应在我的配置中随处可见。我以前需要保留这样的代码行来告诉 Emacs 每个语法文件的位置： 在 Emacs 31 中，像 TypeScript、TSX、Rust、TOML、YAML 和 Dockerfile 等语言的语法源文件直接放到了模式代码内部，所以我留下了一串 `;; EMACS-31 此内容现已在模式代码中定义` 的注释，标记着每个我可以在 31 发布后删除的代码块。能用更少的配置完成同样的工作，我随时欢迎。 emacs_31 demo 01 Emacs 还有更多 tree-sitter 方面的改进即将到来。开发人员一直在不懈努力，Yuan Fu 以及其他许多人持续在多个领域改进 tree-sitter 的体验。从更好的语言支持到可用性和性能提升，Emacs 中的 tree-sitter 正以惊人的速度发展。 ## 内置的 markdown-ts-mode（实验性） Emacs 31 内置了 `markdown-ts-mode`，这个功能我很看重。它是我发起的。这个模式源于我 2025 年初向 emacs-devel（https://lists.gnu.org/archive/html/emacs-devel/2025-02/msg00810.html）发送的一份提案，其中包含了这个想法和第一版代码。 如果让你觉得这是我一人的功劳，那就对这个模式不公平了。**Stéphane Marks** 后来加入进来，卷起袖子，成为了该模式的共同作者。正是他的精力，让这个模式今天用起来如此舒适。他不是只提交一两个补丁就完事了；他留了下来，将这个模式推向了远超我最初草图的水平，并精心打磨那些将“能用”变为“好用”的细节。我接下来要夸耀的许多精加工都是他的功劳。这个模式现在是 *我们的*，并且因此而更好了。 看着一个想法从邮件列表的消息变成核心代码，并且在这个过程中遇到了一位出色的合作者，这是待在 Emacs 社区中最有成就感的事情之一。 它带来的不仅仅是颜色高亮，以下是我想要展示的部分： ✔️ **Org 用户会感到宾至如归。** 键盘快捷键和编辑体验与 Org 相近：导航标题、折叠章节、在结构元素之间移动。如果你的手记住了 Org，你无需重新学习 Markdown。 ✔️ **实时、带颜色的代码块，即使是非 tree-sitter 语言也支持。** 这是我最喜欢的功能。一个围栏代码块会使用该语言的 *真实* 主要模式进行字体化，而不是被当作纯等宽文本处理。它还能访问 Emacs 自己的内部模式，因此一个 `\`\`\`elisp` 块会以真正的 Emacs Lisp 字体锁定显示，其他内置模式也是如此。无需额外设置，你的代码示例内部就能获得正确的语法高亮。 ✔️ **内联图片查看。** 图片链接会在缓冲区中渲染，因此一个带有截图或图表的 Markdown 文档读起来就像是一份文档，而不是满屏的 `\!\[\]\(path\)` 噪音。 以及许多其他可发现且正在开发的功能。 总之，这些功能让在 Emacs 内 *编写* 和阅读 Markdown 变得舒适，而不是给 `.md` 文件生硬地加上一个语法高亮器。 我想提前说明一个注意事项：`markdown-ts-mode` 仍然是 *实验性* 的，你需要主动选择启用它。正如 `markdown-ts-mode.el` 的头部注释所说，它还没有接入 `auto-mode-alist`，因此不会自动接管 `.md` 文件。目前，你可以通过 `M-x load-library RET markdown-ts-mode` 加载该库，然后在缓冲区中启用它，或者如果你胆子够大，可以自己将其添加到 `auto-mode-alist`。 Stéphane 和我正在努力让它能在下一个 Emacs 版本中被认为 *准备好了*，而这正是你可以发挥作用的地方。如果你试用它并遇到了粗糙的边缘，或者它运行得很好，我们都希望能听到你的反馈。请通过 `M-x report-emacs-bug` 将反馈发送到 bug 列表（https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs），或者直接联系我和 Stéphane。真实世界的使用才能将一个模式从“实验性”推向“完成”，所以不要害羞。 emacs_31 demo 02 更多截图请见此处（https://github.com/LionyxML/markdown-ts-mode-lab/tree/main/demo）。 ## Eglot 使用 markdown-ts 渲染文档（同样，仍属实验性） 说到 Markdown，Emacs 31 中的 Eglot 可以使用相同的内部模式渲染 LSP 文档，而不是退回到纯文本： `markdown-ts-view-mode` 让你获得格式化的悬停文档，而无需额外引入任何东西。此处同样适用 *实验性* 的注意事项，因为它依赖于 `markdown-ts-mode`，所以将其视为一个需要主动启用的功能，而不是一个现成的默认设置。我还关闭了 `eglot-code-action-indications`。新的内联“你可以在此处执行代码操作”提示虽然巧妙，但某些语言服务器会让它们变得很嘈杂，所以我将其关闭。 emacs_31 demo 03 这里也有一些变动：`eglot-events-buffer-size` 正在被 `eglot-events-buffer-config` 取代，因此我在旧变量旁边留了一个 `;; EMACS-31 -- 还需要它吗？` 的注释，以便稍后清理。 ## eldoc 于点位处 这是一个我很喜欢的小功能： 启用此选项后，eldoc 会显示光标所在位置的帮助文本，无需我主动调用。配合 `eldoc-echo-area-prefer-doc-buffer`，它让浏览不熟悉的代码变得更加有指导性。 ## 更智能、更积极的补全 小缓冲区和补全机制得到了几个新的开关： `completion-eager-update` 和 `completion-eager-display` 会在你输入时刷新补全界面，而不是等你主动请求。如果你没有运行像 icomplete 这样的工具，将急切显示设置为 `t` 本身就能提供良好的开箱即用体验。而 `minibuffer-visible-completions` 设置为 `'up-down` 则允许你使用方向键在可见的候选方案中移动，这终于感觉很自然了。 icomplete 也得到了关注，这是我直接参与的另一项功能。Emacs 31 包含了来自 bug#75784（https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-03/msg02638.html）的补丁，这个补丁是我提出并完成的。它为 icomplete 带来了垂直的 *缓冲区内部* 行为以及前缀指示器。我喜欢的一个副作用是：我在配置中一直携带的一个巨大的兼容性代码块终于可以删除了： ## 窗口布局操作 这是一组有趣的新命令，用于重新排列窗口布局，而无需手动拆分和杀死窗口： Transpose 交换你的水平和垂直排列，rotate 旋转整个布局，flip 命令则从左到右或从上到下镜像布局。如果你曾经构建了一个三窗口布局，然后又希望编辑器窗格在另一侧，这些命令可以完成这项工作，并且在操作过程中保持每个缓冲区的位置不变。 ## 驻留在侧窗口的 Speedbar Speedbar 已经存在很久了，但在 Emacs 31 中，它学会了驻留在合适的侧窗口中，而不是一个单独的框架： `speedbar-window` 将其停靠在侧边，就像现代的文件树一样。在平铺式桌面或单显示器笔记本上，这比旧的浮动框架行为好得多。宽度限制可以防止它与我的其他窗口冲突。 emacs_31 demo 04 ## VC 改进 一些我愉快地启用的版本控制改进： `vc-dir-hide-up-to-date-on-revert` 是我最喜欢的一个。刷新 `vc-dir` 缓冲区现在会自动隐藏已是最新的文件，因此我不再需要我的 `g` 键技巧——先调用 `vc-dir-refresh` 再调用 `vc-dir-hide-up-to-date`。又一个标记为删除的代码块。`vc-allow-rewriting-published-history` 则是对像 Jujutsu 这样的工作流程以及强制推送功能分支的点头认可，在这些场景中，重写已推送的历史是一个刻意的操作。 ## 可编辑的 xref 缓冲区 这个不是变量，而是我配置中提醒我 *移除* 一个自定义 hack 的注释： 请允许我放纵一下，详细讲讲这个功能，因为我参与了其中，这也展示了功能是如何进入 Emacs 的。 痛点是这样的：Dired 和 grep 缓冲区长期以来都有一种“编辑”工作流。在 Dired 中，你可以切换到 `wdired-mode`；在 grep 缓冲区中，你可以按 `e` 进入 `grep-edit-mode`。批量重命名和批量查找替换在那里感觉非常自然。然而 xref 缓冲区没有这样的功能。唯一的编辑操作是 `r`（`xref-query-replace-in-results`），它只能使用正则表达式，并且不允许你编辑单独的行。我非常依赖 `project.el` 和 xref 进行导航和重构，我经常发现自己不得不重新用 `M-x grep` 执行相同的搜索来获得一个可编辑的缓冲区。这是一条恼人的绕路，因为 xref 已经包含了所有需要的信息。 所以在 2026 年 3 月，我向 `bug-gnu-emacs` 发送了一个补丁，提出了一个小命令 `xref-export-to-grep`，绑定在 `*xref*` 缓冲区的 `E` 键上。它会重新获取 xref 条目，格式化为 `文件:行号:内容`，然后放入一个 grep 模式缓冲区，你可以在那里按 `e` 并像往常一样编辑。没什么花哨的。它连接了两个已经存在的功能，而且我私人携带这个片段已经有一段时间了。 接下来发生的事情正是我热爱这个社区的原因。维护 xref 的 Dmitry Gutov 看了我的补丁，并且对我方法的 *用户界面* 提出了异议。我的命令需要在缓冲区之间跳转，而且一旦你进入 grep 缓冲区，你还得知道按哪个键。他问了一个比我回答的问题更尖锐的问题：我到底在意的是 grep 导出，还是说 **xref 缓冲区让你就地编辑** 会更好？ 这个重新定义是对的。我告诉他我并不执着于通过 grep 绕路。在 xref 缓冲区本身进行内联编辑，支持在匹配项之间进行多行编辑，这将完全消除整个往返过程。几天后，他编写并推送了 `xref-edit-mode`。它省去了额外的步骤，并且在大型 xref 缓冲区上运行得更快。我最初的 `xref-export-to-grep` 仍然可以作为可选命令存在，但没有默认键绑定，但内联模式是更好的解决方案，也是我现在用的。 这个讨论并没有就此停止。它衍生出了与 Juri Linkov 关于 `*-edit-mode` 系列（occur/grep/xref，它们会正常写回每个缓冲区）与 `wdired` 的“先排队所有操作、再 `C-x C-s`”模型的更广泛的设计讨论，以及未来的“实时”搜索 UI 可能会如何更不同地呈现结果。作为记录，以下是我在那次讨论中提到的安全网，一个我从 Protesilaos 那里学到的技巧，让我在 `save-some-buffers` 期间，在保存之前可以按 `d` 来比较缓冲区与其文件： 回到正题，最终结果是：Emacs 31 提供了可编辑的 xref 缓冲区，我的配置删除了一个自制的工作区，而最终落地的功能比我最初提出的更好，因为维护者问对了问题。能在这个循环中扮演一个小小的角色，是我乐于在 `master` 上生活的很大一部分原因。完整的来回讨论是公开的，详见 bug#80616（https://debbugs.gnu.org/cgi/bugreport.cgi?bug=80616），如果你感兴趣的话。 所以，如果你想尝试一下。在 `C-x p g` 之后，搜索类似 `FontAwesomeIcon` 的内容。现在按 `e` 进入编辑模式，进行你的编辑，然后按 `C-c C-c` 确认。 emacs_31 demo 05 ## ERC 变得更整洁 一些 IRC 的改进，因为我生活在 ERC 中： 这使得 ERC 只为新打开的目标缓冲区插入之前的日志，这正是我重新加入频道时想要的行为。还有一个我最喜欢的小修复：在 Emacs 31 中，`scrolltobottom` 模块不再依赖于 `erc-fill-wrap`，因此我可以删除那个手动为旧版本添加它的条件语句。感谢解开这个问题的所有人。 ## 各种生活质量小开关 还有一些小的改进，它们每个都不值得单独一节，但绝对值得拥有： 其中几个值得多说一句： ✔️ **`kill-region-dwim`** 修复了一个几十年的小毛病。将其设置为 `'emacs-word`，然后在没有激活区域的情况下按 `C-w`，它会向后删除一个单词，而不是报错。不再有“标记未激活”的中断。 ✔️ **`view-lossage-auto-refresh`** 将 `C-h l` 变成了你最近按键的实时视图。当我进行屏幕共享或教学时，人们可以实时看到我按下的键。 ✔️ **`ielm-history-file-name`** 让我的 IELM 临时会话能在重启后存活下来，就像 `comint` 和 shell 已经能做到的那样。 ✔️ **`native-comp-async-on-battery-power nil`** 可以省电笔记本：当我在火车上未插电时，不会因为后台本地编译而突然风扇狂转。 ✔️ **`tty-tip-mode`** 为终端带来了工具提示，对于在 `-nw` 模式下运行 Emacs 的我们来说是一个很好的补充。 ## 荣誉提名：term 不再吞行 这个变化没有配置行，因为没什么可配置的。一个 bug 被修复了，这让我高兴得有点过分。 很长一段时间，`term`（以及 `ansi-term`）有一个讨厌的 *吞行* 习惯。全屏、光标寻址的程序会导致显示混乱，当程序重绘时，行会被吃掉或放错位置。这正好影响了你最需要一个真正终端的程序：`htop`、`nethack`，任何基于 curses 的程序在 Emacs 的终端里几乎无法使用。 Emacs 31 修复了这个问题。`term` 现在可以正确重绘了，我可以运行 `htop` 来查看进程，或者启动 `nethack` 进行一个“快速”的休息，而缓冲区不会变成一团乱。这听起来很小，但它消除了我不得不使用外部终端模拟器的最后一个理由之一。 emacs_31 demo 06 emacs_31 demo 07 ## 荣誉提名 2：Modus 5 主题！ 感谢 Protesilaos，Emacs 现在内置了多个 modus 主题： ✔️ `modus-operandi-deuteranopia` -- 针对绿色盲优化的主题，白色背景。 ✔️ `modus-operandi` -- 优雅、高可读性的主题，白色背景。 ✔️ `modus-operandi-tinted` -- 优雅、高可读性的主题，浅赭色背景。 ✔️ `modus-operandi-tritanopia` -- 针对蓝色盲优化的主题，白色背景。 ✔️ `modus-vivendi-deuteranopia` -- 针对绿色盲优化的主题，黑色背景。 ✔️ `modus-vivendi` -- 优雅、高可读性的主题，黑色背景。 ✔️ `modus-vivendi-tinted` -- 优雅、高可读性的主题，黑色背景。