Emacs 31 还没正式发布。
但已经有人基于 emacs-31 分支和 master 日常使用数月，并把一批进入或接近进入核心的变化梳理出来。这里最有意思的地方，不是“又加了几个功能”。
真正的变化是：Emacs 正在把一部分过去靠外部包、个人配置片段、兼容补丁解决的问题，收回到核心里。
这对只拿 Emacs 写普通文本的人，可能没那么强烈。受影响最大的是两类人：长期维护配置的 Emacs 高级用户，以及把 Emacs 当开发环境用的程序员。他们最常见的成本不是“不会用”，而是配置越滚越厚，几年后自己也不敢删。
Emacs 31 的看点就在这里：它不是要把 Emacs 变成 VS Code，也不是要替代现代 IDE。它更像在清理一层“用户自救层”。
Tree-sitter 自动化：最该先看的变化
Emacs 31 里，Tree-sitter 是最关键的一条线。
过去想用 *-ts-mode，常见做法是手写 treesit-language-source-alist，再安装 grammar，还要处理本机编译工具链。配置能跑，但不轻。机器一换、系统一变，就容易出小问题。
这一版里，treesit-enabled-modes 可以把已有 Tree-sitter 变体的主模式切过去。treesit-auto-install-grammar 则会在缺少 grammar 时提示获取和构建。
这很接近第三方包 treesit-auto 提供的体验。区别在于，它开始进入 Emacs 核心。
TypeScript、TSX、Rust、TOML、YAML、Dockerfile 等语言的 grammar 来源，也开始由相关模式自身提供。对老用户来说，这意味着配置里一长串“告诉 Emacs 去哪里找语法”的代码，有机会被删掉。
| 能力 | 过去常见做法 | Emacs 31 的方向 | 对用户的影响 |
|---|---|---|---|
| Tree-sitter | 手写 grammar 来源，手动安装 | 自动启用，缺失时提示安装 | 少维护配置，少处理工具链细节 |
| Markdown | 依赖外部 markdown-mode | 内置实验性 markdown-ts-mode | 可试用，但不该当稳定默认 |
| LSP 文档 | Eglot 文档常退回纯文本 | 可用 markdown-ts-view-mode 渲染 | hover 文档更可读 |
| xref 批量编辑 | 借 grep 或自写流程 | xref-edit-mode 内联编辑 | 搜索后修改少绕一步 |
限制也要说清楚。
Tree-sitter 自动化不等于所有语言体验都成熟。它仍依赖对应 grammar、主模式集成和本机编译环境。尤其在 Windows、终端环境、缺少编译工具链的机器上，最终体验还要看默认策略和平台适配。
所以更稳妥的动作不是立刻删配置。
已经在用 treesit-auto 或大量手写 grammar 来源的用户，可以先在单独分支里测试 Emacs 31。能删的配置做标记，等正式版默认行为确定后再清理。团队共享配置更应该延后合并，避免把开发分支行为当成稳定承诺。
Markdown 和 xref：核心开始接住工作流
markdown-ts-mode 是另一个信号。
它已经进入 Emacs 31，但仍是实验性内置模式。需要用户手动加载，或自行加入 auto-mode-alist。它还不会默认接管 .md 文件。
这一点很重要。不能把它写成“Emacs 31 已经有稳定默认 Markdown 模式”。目前更准确的说法是：Emacs 核心开始接住 Markdown，但还没把它推到默认入口。
markdown-ts-mode 的方向，是让 Markdown 在 Emacs 里更像一个可读、可写的文档环境。它借鉴 Org 用户熟悉的标题导航和折叠体验，代码块可调用真实 major mode 做高亮，图片链接也可在 buffer 内显示。
原作者 Rahul Juliato 披露，这个模式来自 2025 年初发往 emacs-devel 的提案。后来 Stéphane Marks 参与，并成为共同作者。
这类路径很 Emacs：不是产品经理给一张路线图，而是用户把自己的痛点写成补丁，维护者和社区再把边界磨清楚。慢，但有脉络。
xref-edit-mode 也类似。
作者最初提议把 xref 结果导出到 grep buffer，再用 grep-edit 批量修改。xref 维护者 Dmitry Gutov 追问后，最后落地的是直接在 xref buffer 内编辑。
这个结果更干净。
对经常用 project.el、xref 做项目搜索和重构的人来说，少一次跳转，少一个临时 buffer，就是少一次出错机会。它不替代大型 IDE 的重构能力，但能把 Emacs 里很常见的一段手工流程缩短。
这里的现实约束也很清楚：Markdown、xref、Eglot 文档渲染这些变化，还不能支撑“Emacs 全面追上现代 IDE”的结论。它们更像把日常工作流里的小断点补上。积跬步，少折腾。
小改动的价值：让老配置慢慢失业
Emacs 31 还有一批分散的小变化。
补全侧，completion-eager-update、completion-eager-display 让候选随输入更新。minibuffer-visible-completions 可以用上下键移动候选。icomplete 获得垂直 in-buffer 行为和前缀指示。
窗口侧，新增转置、旋转、翻转命令。Speedbar 可以停靠在 side window，不再只能像老工具窗那样另开 frame。
VC 侧，vc-dir-hide-up-to-date-on-revert 能在刷新时自动隐藏已更新文件。vc-allow-rewriting-published-history 则更贴近 Jujutsu、功能分支 force push 这类现实工作流。
还有一些更小的修补：kill-region-dwim 可让无选区 C-w 删除前一个词；ielm-history-file-name 让 IELM 历史跨重启保留；tty-tip-mode 给终端 Emacs 带来 tooltip；ERC 和 eldoc 也有细节补强。
单看每一项，都不像大新闻。
合起来看，它们指向同一件事：很多人配置里那些“我只是想让 Emacs 正常一点”的片段，开始有机会退出历史舞台。
这也是 Emacs 31 和 VS Code、Neovim 的差别。
VS Code 的强项是默认体验统一，扩展市场成熟。Neovim 的强项是 Lua 配置和插件生态活跃。Emacs 31 走的不是这两条路。它更像在把多年散落在用户配置、第三方包和邮件列表里的共识，慢慢收进核心。
对高级用户，接下来最实际的动作有三个：
- 不急着把开发分支当生产基线，但可以开一个测试配置分支。
- 重点检查 Tree-sitter、Markdown、补全、xref、VC 相关旧配置，标出未来可能删除的部分。
- 等正式版确认默认值后，再决定哪些外部包可以退场。
真正要观察的，也不是“Emacs 31 又加了多少功能”。
更该看三件事：Tree-sitter 自动安装的最终默认策略是否保持；markdown-ts-mode 何时从实验走向默认关联 .md；这些能力在不同平台上的表现是否稳定，尤其是 Windows、终端环境和缺少编译工具链的机器。
如果这些变量处理不好，Emacs 31 的进步会主要留在愿意编译开发分支的老用户手里。
如果处理得好，它的意义就很直接：少一批外部包，少一批旧配置，少一点 Emacs 用户长期习惯的自救成本。