Neomacs：用 Rust 和 GPU 重写 Emacs，兼容性赌注能赢吗？
NEO Emacs (WIP)：使用 Rust 编写的 GPU 驱动的 Emacs，具有现代显示引擎。旨在实现现代设计和多线程 Elisp、10 倍性能、零暂停并发 GC 和 100% Emacs 兼容性。
秒懂
- 它是什么？
- Neomacs 是一个用 Rust 重写 Emacs 内核、用 wgpu 驱动 GPU 显示引擎的进行中项目。它承诺 100% 兼容现有配置和包，但当前状态和架构选择决定了它只适合特定人群。
- 适合谁用？
- 如果你是一个愿意接受频繁破坏性变更、喜欢在 Lisp 层以下折腾渲染效果的 Emacs 重度用户，或者你受够了 xdisp.c 的黑盒，Neomacs 值得你每周花时间跟进。但如果你需要稳定的日常编辑环境，或者依赖某些冷门 C 扩展包，现在不是迁移的时机。
- 能商用吗？
- 可以，但有条件。GPL-3.0 是 copyleft 许可证：如果你分发包含它的软件，就必须以同一许可证公开该软件的源代码。只在内部运行、不对外分发，则不会触发这项义务。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Rust（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它要解决什么问题
GNU Emacs 的显示引擎 xdisp.c 有大约五万行 C 代码，维护和扩展都很困难。Neomacs 的作者认为，Emacs 的 hackability 在 C 层就断了，用户能改 Lisp，但改不了渲染逻辑。Neomacs 用 Rust 重写了整个 C 核心，包括求值器、字节码 VM、GC 和 portable dump，然后用 wgpu 在 GPU 上渲染文本和图像。项目的目标不是做一个新编辑器，而是让 Emacs 的生态原封不动地跑在一个现代底座上。README 里明确写着，GNU Emacs 是测试 oracle，每个重写的子系统都要和原版行为一致。这个定位决定了它面向的是那些已经深度依赖 Emacs 配置和包的用户，而不是想换编辑器的新手。
架构：两线程和 GPU 渲染
Neomacs 的架构文档描述了一个两线程模型：Emacs 线程拥有 Elisp 运行时和编辑器状态，渲染线程拥有 GPU。这两个线程通过某种机制通信，但 README 没有给出具体的同步细节。显示引擎用 wgpu，这是一套跨平台的 GPU 抽象，支持 Vulkan、Metal、DX12 和 GL。这意味着同一个二进制可以在 GUI 和 TTY 下运行，TTY 模式用 neomacs -nw 启动。值得注意的设计是，渲染效果本身暴露给 Elisp，包括光标模式、滚动效果、缓冲区切换动画，甚至 WGSL 着色器。这是 GNU Emacs 做不到的，因为 xdisp.c 是 C 黑盒。但反过来，这也意味着渲染线程和 Elisp 线程之间的数据竞争问题需要精心设计，目前文档没有给出答案。
安装与构建：从包到源码
Neomacs 在 GitHub Releases 提供 Linux 的 AppImage、.deb、.rpm 和 tarball，macOS 和 Windows 是实验性支持。如果你要自己构建，README 给出了三条命令：git clone 仓库，然后用 nix develop 进入开发环境（可选但推荐），最后运行 cargo xtask fresh-build --release。这个命令会编译 Rust、引导 Elisp 并生成 portable dump。构建完成后运行 ./target/release/neomacs。注意，这个构建流程依赖 Nix 或系统包管理器提供的平台依赖，具体清单在 docs/building.md 里。对于不想用 Nix 的用户，你需要手动安装 wgpu 所需的 Vulkan 驱动，以及 GStreamer 和 VA-API 才能用视频功能。
兼容性：95% 的 oracle 测试意味着什么
README 的状态表显示，GNU Emacs 兼容性测试套件大约完成了 95%。这个数字来自项目自己的报告，没有独立验证。它的测试方法是用 GNU Emacs 作为 oracle，把 Neomacs 的每个子系统输出和原版对比。这个思路很扎实，但 95% 不等于你可以直接替换。剩下的 5% 可能包括边缘情况、宏展开的微妙差异，或者某些 C 扩展包的二进制接口。Neomacs 是 GNU Emacs 的硬分叉，Lisp 树同步到 emacs-31.0.90，这意味着它继承了 Emacs 的 GPL-3.0 许可证，但任何基于它做的修改都必须开源。如果你依赖某些需要编译 C 代码的包，比如原生 LSP 客户端，你可能需要等这些包适配 Rust 核心。
媒体功能：视频、浏览器和终端
Neomacs 最吸引眼球的功能是能在缓冲区里内嵌 4K 视频、WebKit 浏览器和 GPU 终端。这些功能通过 DMA-BUF 零拷贝实现，视频用 GStreamer 和 VA-API 解码，浏览器用 WPE WebKit，终端用 Alacritty。README 里的演示链接显示这些功能已经能跑，但状态表把它们标为 experimental。这意味着它们可能不稳定，而且依赖 Linux 特有的 DMA-BUF 机制，macOS 和 Windows 上大概率不可用。对于想用 Emacs 作为统一工作台的用户，这些功能很有吸引力，但你要接受它们可能随时坏掉。而且，这些媒体功能目前没有文档说明如何从 Elisp 配置，只有动画目录 docs/animations.md 列出了 8 种光标模式、21 种滚动效果和 10 种缓冲区切换效果。
性能主张与多线程 Elisp 的现状
项目描述提到 10x 性能和零暂停 GC，但 README 的状态表显示，真正的多线程 Elisp 和零暂停 GC 还处于设计或实验阶段。JIT 编译和内联缓存标记为 working，但正在优化。这意味着 README 里的性能数字更多是愿景，不是当前可验证的事实。实际上，README 没有给出任何基准测试数据，只有架构文档的链接。如果你因为性能而想迁移到 Neomacs，现在没有证据支持这个决定。GPU 渲染确实可能比 CPU 渲染快，但 Elisp 执行速度才是大多数编辑操作的瓶颈。项目作者承认这些还在 profiling 和 tuning 阶段，所以你应该把它当作一个早期项目，而不是性能优化后的成品。
替代方案：Neovide 和原生 Emacs 的对比
如果你想要 GPU 加速的编辑器体验，最接近的替代品是 Neovide，它是一个用 Rust 写的 Neovim 前端，同样用 GPU 渲染，也提供了光标动画。但 Neovide 和 Neomacs 的路线完全不同：Neovide 只替换前端，保留 Neovim 的 C 核心；Neomacs 则把整个核心重写成 Rust。这意味着 Neovide 的兼容性风险远低于 Neomacs，你不需要担心 Elisp 解释器行为不一致。但 Neovide 只支持 Neovim，不支持 Emacs 的 Lisp 生态。另一个选择是继续用 GNU Emacs 的 native-comp 分支，它在性能上做了很多优化，但没有 GPU 渲染。如果你只是想要动画效果，GNU Emacs 29 已经支持了一些像素滚动，但远不如 Neomacs 的丰富。
维护成本与许可证风险
Neomacs 的维护成本很高。它是硬分叉，意味着每一次同步上游 Emacs 的 Lisp 树都需要处理冲突。项目最近发布了 v0.0.15，距离 v0.0.14 不到三周，说明开发节奏很快，但也意味着 API 可能频繁变动。如果你基于 Neomacs 写自定义 Elisp，可能需要经常调整。许可证是 GPL-3.0，和 Emacs 一致，这没有额外限制，但如果你分发修改版，必须开源。另一个成本是依赖链：wgpu、winit、cosmic-text 这些 Rust crate 更新频繁，Neomacs 需要持续跟进。对于企业用户，这个项目的长期维护没有商业背书，完全依赖作者个人和社区捐赠。README 里提到了 GitHub Sponsors，但没有任何公司支持。
编辑结论
如果你是一个愿意接受频繁破坏性变更、喜欢在 Lisp 层以下折腾渲染效果的 Emacs 重度用户，或者你受够了 xdisp.c 的黑盒，Neomacs 值得你每周花时间跟进。但如果你需要稳定的日常编辑环境，或者依赖某些冷门 C 扩展包，现在不是迁移的时机。在尝试之前，先确认你的发行版能安装 wgpu 所需的 Vulkan/Metal 依赖，并准备好回退到 GNU Emacs。项目当前约 95% 的 oracle 测试通过率听起来不错，但最后 5% 往往是最难啃的骨头。Neomacs 的成败取决于它能否在 Rust 重写的同时保持字节级行为一致，而这一点目前还没有任何证据能证明。
社区笔记