Emacs 用户等了快二十年,才等到一个终端模拟器支持 Kitty 图形协议和 OSC 8 超链接。新出的 Ghostel 做到了——但它没自己写协议解析器,而是直接把 Ghostty 的引擎 libghostty-vt 搬进了 Emacs。
这不是又一个"更快的 vterm"。vterm 用的是 libvterm,eat 是纯 Elisp,两者都没跟上这几年终端协议的进化。Ghostel 借的是 Ghostty 这几年在协议解析上砸的功夫,一次性搬了过来。
Ghostel 是什么:借引擎,不造轮子
Ghostel 分两层。Zig 写的原生动态模块管终端状态、渲染和本地 PTY 的输入输出。Elisp 管按键、缓冲区、命令和远程集成。这套分层思路,作者承认是照抄 emacs-libvterm。
真正该比的对象是 vterm 和 eat,它们才在同一条赛道上。拿 Ghostel 硬套 Ghostty 本体,没有意义。
| 项目 | 底层引擎 | Kitty 键盘/图形协议 | OSC 8 超链接 | 依赖形式 |
|---|---|---|---|---|
| vterm | libvterm | 不支持 | 不支持 | 本地编译 C 模块 |
| eat | 纯 Elisp | 不支持 | 不支持 | 无原生依赖 |
| Ghostel | libghostty-vt | 支持 | 支持 | 自动下载原生模块 |
看点:协议能力升级,门槛换了个地方
对多数用户,最直接的变化是:首次使用自动下载原生模块,不用本地装编译工具链。这解决了 vterm"先装 C 编译环境"的老问题。
但依赖没消失,只是换了地方。以前是本地编译,现在是信任一个没编译过的二进制。项目页单独列了 Windows 的注意事项,说明跨平台体验还没抹平。
性能数据目前没有公开测试。协议能力的领先是确定的,渲染速度谁快还说不好。
远程场景是 Ghostel 补的另一块:TRAMP 集成、远程 shell 自动注入、远程 xterm-ghostty terminfo 安装选项。这是 eat、vterm 常年被吐槽的短板——本地体验再好,一到 SSH 就打折扣。
重度终端用户,尤其是常跑远程会话的开发者,值得现在就装一个试试。只用本地 shell、不需要图形协议的轻度用户,继续用 eat 更省心——它没有原生依赖这道信任题要过。
我的判断
vterm 卡在协议能力上太久了。它诞生的年代还没有 Kitty 图形协议,没有 OSC 8,libvterm 本身也不再频繁迭代。eat 走另一条路——纯 Elisp,零依赖,换来的是省心,代价是性能和协议能力的天花板。Ghostel 选了第三条路。
荀子说"君子生非异也,善假于物也"——不是天赋异禀,是善于借力。Emacs 这个生态一直这么长大:借 ripgrep 做搜索,借 LSP server 做补全,现在借 Ghostty 的引擎做终端。
我不太买账的地方是维护责任。原生模块的长期维护落在一个第三方项目身上,不是 Ghostty 官方。Ghostty 升级引擎,Ghostel 跟不跟得上,是个悬而未决的问题。vterm 的教训就是维护跟不上,协议慢慢过时,能力再强也是过去式。
接下来该盯的,是 Ghostel 能不能撑过 Ghostty 下一次大版本更新——引擎迭代快,插件跟不跟得上,决定这条路线能走多远。
Emacs 终端等了二十年才等到现代协议支持。这次真正的成本不是性能,是要不要为了协议能力,接受一个自己不完全控制的原生依赖。