Emacs 31 把 markdown-ts-mode 塞进了内核，这是基于 tree-sitter 的新版 Markdown 编辑模式，官方标注为 experimental。一篇流传较广的非官方教程详细讲了怎么手动加载它、怎么装两套语法（markdown 主语法和 inline 内联语法），并称赞这个模式已经覆盖了 CommonMark 全部规范和大部分 GFM，还能对接 pandoc 和 gfm 转换器。
听起来像是一次顺理成章的升级。但 experimental 这个词从来不是随便贴的标签，Emacs 31 的源码里明确写着这个模式还有未解决的问题。教程只教你怎么点亮它，没告诉你点亮之后会遇到什么。
装上容易，用顺难
markdown-ts-mode 依赖外部编译的 tree-sitter 语法，装的时候要联网克隆、本地编译，第一次用还得挨个给 YAML、elisp 之类嵌入语言补装语法包。这本身就是 tree-sitter 系模式的通病，不算新鲜。
真正值得盯的是装完之后的可用性。GitHub 的问题追踪器里挂着几十个未关闭的 issue，其中不少不是边缘 bug：fill-region 在列表之后会卡死或者破坏段落间距，普通列表内容会被误判成 Setext 标题，写不完整的类链接标点也会被错误识别成链接。这些都是日常写作会真实碰到的操作，不是极端场景。
- 风险.链接误判、标题误判、fill-region 卡死，都是高频写作动作，不是罕见边缘情况。
语法本身就承认解析不准
比 experimental 标签更深一层的限制，是这个模式背后的 tree-sitter-markdown 语法。Emacs 31 的 markdown-ts-mode 是针对该语法 0.4.1 版本测试的，而这套语法自己声明：Markdown 的语法过于宽松、方言过多，用形式化语法树做完全准确的解析本来就不现实，它也不建议在要求完全解析正确性的场景里使用。
这句话的分量比"还在测试"重得多。tree-sitter 的卖点是增量解析和结构感知，前提是语言本身有明确文法。Markdown 天生没有——同一段文字在不同渲染器里可能长出不同的结构树。也就是说,即便 Emacs 团队把所有已知 issue 修完，底层语法的解析上限已经写死在那里了。
社区两极分化，老牌模式没被取代
Reddit 上的反馈说明这不是纯粹的技术评估，而是使用场景决定体验。轻度写 Markdown 的用户反馈总体正面，尤其喜欢它模仿 org-mode 的结构化编辑方式，标题升降级、整段落移动都用得顺手，一些人已经拿它当默认模式用。
但抱怨集中在几个高频功能上：没有类似 org-mode C-c C-l 的快捷插链接命令，嵌套标题的折叠和移动有边缘情况会出错，表格操作的按键习惯跟 org 表格不一致。文档也不完整，很多功能得靠自己在 issue 里翻。
对照社区里已有的功能对比结论，markdown-ts-mode 在表格编辑、列表重排、导出预览这些"高阶编辑命令"上，明显还没追上老牌的 MELPA markdown-mode。它的强项目前主要体现在解析和语法高亮层面，不是实际编辑效率上。原文说的"功能丰富"，指的是覆盖了 CommonMark 和 GFM 的解析规范，跟"编辑体验完整"是两件事。
语法能覆盖规范，不代表编辑能覆盖习惯。
谁该现在换，谁该再等等
轻量使用者——写写笔记、博客草稿、README，很少碰复杂表格或脚注——现在切换问题不大，折叠标题、整段移动这些日常操作已经够用，而且这是 Emacs 官方要长期维护的方向。
重度依赖表格、脚注、wiki 链接扩展语法的用户,建议先留在 MELPA markdown-mode。旧版 MELPA 的 markdown-ts-mode 仓库在 Emacs 31 上已经装不进去,该仓库现在主要用来做问题追踪和实验，不是可用的替代品。
- 结论.适合先试的是轻文本场景，适合再等等的是重表格、重扩展语法的场景。
接下来该盯的不是 Emacs 31 正式发布日期,而是两个更具体的信号:GitHub issue 数量是不是在收敛,以及 tree-sitter-markdown 语法有没有出新版本去修增量解析的已知 bug。语法层的限制不解决,experimental 这顶帽子摘不掉。