Libghostty 即将到来

# Libghostty 即将到来 来源：https://mitchellh.com/writing/libghostty-is-coming 两年多前，在我最早关于 Ghostty 的公开演讲之一（https://mitchellh.com/writing/ghostty-and-useful-zig-patterns）中，我分享了对 `libghostty` 的愿景：一个可嵌入的库，任何应用程序都能嵌入自己的、功能完整、现代且快速的终端模拟器。Libghostty 终于开始成形了，我很兴奋地分享更多关于其计划的细节。第一个 `libghostty` 库将是 `libghostty-vt`：一个零依赖的库，提供用于解析终端序列和维护终端状态的 API，直接提取自 Ghostty 真实世界已验证的核心。它甚至不需要 libc！ **免责声明**：这篇文章主要是关于 libghostty 的路线图更新，并宣布即将推出的第一个可交付组件。Zig API 现已可用进行测试，但 C API 尚未就绪，很快就会到来。两者目前都处于早期测试质量，尚不适合普遍使用。 --- ## 为什么需要 libghostty？ 首先来谈谈我认为 libghostty 必须存在的原因。有成百上千的程序实现了某种形式的终端模拟。最明显的是实际通用终端模拟器，如 Ghostty、Kitty、iTerm2 等。但像 tmux（https://github.com/tmux/tmux）或 zellij（https://zellij.dev/）这样的终端复用器也是完整的终端模拟器。¹ 编辑器也嵌入自己的终端模拟器，例如 JetBrains 产品的 jediterm（https://github.com/JetBrains/jediterm）、VS Code 的 Xterm.js（https://xtermjs.org/）、或 Zed 中的 Alacritty（https://github.com/zed-industries/zed/blob/a0514af58955a21401b4c10918a45c9c241a4a74/Cargo.toml#L444）。 除了功能完整的终端模拟器，许多网站和应用程序还实现只读终端模拟，用于显示日志或命令输出。例如，GitHub Actions 输出（https://github.blog/news-insights/product-news/a-better-logs-experience-with-github-actions/#opening-the-door-to-a-more-colorful-experience）解析简单的颜色序列（但仅此而已）。而像 Vercel 或 Render 这样的托管提供商也实现了简单的终端模拟形式，允许在构建日志中清除和重绘行，以及解析颜色。 这些实现中的许多都是临时的一次性解决方案，它们不共享任何公共库或代码库。² 终端模拟是一个经典问题：表面上看起来简单，但实际却充满了意想不到的复杂性和边界情况。³ 因此，大多数实现都不完整、有缺陷且缓慢。⁴ 除了正确性之外，实现任何形式的终端模拟对于大多数开发者而言都是*浪费时间*。终端模拟并非 JetBrains、Visual Studio Code、GitHub、Vercel、Render 等公司的核心业务。如果它们能有一个稳定、可重用且处处一致的解决方案，那将是受益的。我的答案就是 libghostty：一个跨平台、最小依赖的库，通过 C API 暴露功能丰富、正确且快速的终端功能，任何应用程序都可以随处嵌入。 --- ## 起点：`libghostty-vt` 第一个 libghostty 库将是 `libghostty-vt`：一个零依赖（甚至不需要 libc）的库，提供用于解析终端序列和维护终端状态的 API，例如光标位置、当前样式、文本换行等。解析终端序列是终端模拟器的核心功能，无论是完整的终端模拟器（如 Ghostty），还是简单的只读样式视图（如 GitHub Actions 或 Vercel 构建输出），都需要此功能。 状态图（https://vt100.net/emu/dec_ansi_parser）乍看相对简单，但实现起来却意外地难以正确完成。例如，Jediterm 没有正确处理中间字符（https://github.com/JetBrains/jediterm/pull/311），导致广泛支持的“更改光标形状”序列在撰写本文时，在每个 JetBrains 编辑器中都会吞掉一个字符。 对于仅解析样式而言，许多开发者会跳过完整的状态图。他们只是简单搜索一下，解析诸如 `\e\31` 或 `\e[41m` 这样的简单 ANSI 序列，然后宣称“支持颜色”。但仅样式序列远比这复杂得多；例如，它们支持 RGB，而 RGB 本身可能有十几种格式（https://github.com/ghostty-org/ghostty/blob/8cb52323e5575877eef44029c153eda006cece80/src/terminal/color.zig#L400-L438）。而且我至今未发现任何一个网页控制台能正确渲染这个复杂的样式序列（https://github.com/ghostty-org/ghostty/blob/8cb52323e5575877eef44029c153eda006cece80/src/terminal/Parser.zig#L672-L722）。⁵ `libghostty-vt` 旨在解决所有这些。`libghostty-vt` 从 Ghostty 中提取，继承所有现实世界的优势：SIMD 优化的解析、非常好的 Unicode 支持、高度优化的内存使用、经过模糊测试和 Valgrind 测试的稳健代码库、极佳的特性兼容性（例如解析 Kitty 图形协议或 Tmux 控制模式），以及更多。所有这些被封装成一个零依赖的 C API（甚至不依赖 libc），允许轻松嵌入任何流行的语言生态系统。 鉴于其最小体积，`libghostty-vt` 将**广泛可移植**。初始目标将是 macOS 和 Linux 的 `x86_64` 和 `aarch64` 架构，因为这些是 Ghostty 应用程序的主要目标。但我计划将支持扩展到更多目标，例如 Windows、嵌入式设备以及通过 WASM 支持 Web。由于范围更聚焦，`libghostty` 将拥有比 Ghostty GUI 更广泛的支持。 --- ## 长期规划 `libghostty-vt` 只是开始。长期来看，我们将提供更多 `libghostty-` 库，暴露额外功能，例如输入处理（键盘编码是重要的一项）、GPU 渲染（提供一个 OpenGL 或 Metal 表面，剩下的交给我们）、处理整个终端视图的 GTK 组件和 Swift 框架，等等。随着基础组件趋于稳定，我们将继续提供越来越多的功能。这些将作为一个库系列来组织，以最小化依赖需求、代码大小和整体维护复杂度。 --- ## `libghostty-vt` 状态 我刚刚合并了将 `libghostty-vt` 作为 Zig 模块暴露的拉取请求（https://github.com/ghostty-org/ghostty/pull/8840）。该 PR 还包含了一个最小示例程序。如果你是一名 Zig 开发者，现在就可以立即开始使用 `libghostty-vt` 进行实验。C API 尚未就绪，但我*此刻*正在致力于此，它很快就可以用于测试。所有需要的工作都是定义 C API，因为核心逻辑当然已经完全存在并且已被 Ghostty 使用了多年。此外，Ghostty macOS 应用已经使用了一个内部专用的 C API（https://github.com/ghostty-org/ghostty/blob/main/include/ghostty.h）。如果你查看那个内部专用的 C 头文件，请忽略它的混乱。那不是*好的* C API。它仅供内部使用，旨在满足 macOS 应用的需求。这不是一个通用的 libghostty，尽管它已经被真正的商业产品（https://orbstack.dev/）用于嵌入 Ghostty。我们将以全新面貌定义用于更广泛使用的 C API。 我计划将 `libghostty` 与 Ghostty 应用程序分开版本管理。这篇博客文章标志着公开 alpha 版本（不保证 API 稳定性），我希望在 C API 就绪后，能激励一些开发者使用它，并最终编写一些语言绑定。我希望能未来 6 个月内发布一个标记版本的 `libghostty-vt`，但这完全取决于是否准备就绪。 --- ## 寻求反馈 我们正处于 libghostty 的关键设计阶段，正在设计 API，而设计 API 的最佳方式就是听取真正使用者的反馈。Ghostty 是一个使用者，我们有一些社区成员正在开发其他使用 libghostty 的项目，但越多越好！如果你在你的项目或组织中看到 libghostty 的用例，请加入 Ghostty Discord（https://discord.gg/ghostty）并与此项目的开发者合作。如果你不想加入 Discord，可以给我发邮件（本网站页脚中的邮箱）。 在此阶段，`libghostty` 的状态可被视为*alpha*，所以不要期望流畅稳定的体验。我们正在寻找愿意早期参与的黑客。“alpha”质量是针对 API（函数和类型）本身而言。核心逻辑与 Ghostty 共享，且在实际使用中非常稳定和经过验证。 --- ## 下一个前沿 我非常兴奋，Ghostty 应用程序终于达到了足够的稳定性，我们可以开始迈向 `libghostty` 目标。`libghostty` 是 Ghostty 的下一个前沿，我认为它有潜力产生比 Ghostty 作为独立应用程序本身更深远的影响。别担心，Ghostty 应用程序仍有大量改动，这些都不会减弱我对它的兴奋或计划。更广泛使用 `libghostty` 也将带来更功能丰富和更稳定的 Ghostty 应用程序，因为 Ghostty 本身也是 `libghostty` 的使用者。 呼。👻 1. 这些复用器拥有其子进程的 pty，解析所有转义码，管理屏幕状态，最终通过向父终端模拟器发出自己的转义码来“渲染”。↩（https://mitchellh.com/writing/libghostty-is-coming#user-content-fnref-1） 2. 许多网站确实使用了 Xterm.js，GTK 生态系统有 libvte（https://gitlab.gnome.org/GNOME/vte）。但这仅覆盖了很小一部分领域，上述每个例子在其各自的范围内也是有限的。↩（https://mitchellh.com/writing/libghostty-is-coming#user-content-fnref-2） 3. 我花了近 3 年时间研究终端模拟，至今我们仍在发现奇怪的边界情况（https://github.com/ghostty-org/ghostty/pull/7471）。↩（https://mitchellh.com/writing/libghostty-is-coming#user-content-fnref-3） 4. 以下是几个真实且有影响力的例子：Jediterm 未正确处理中间字符（https://github.com/JetBrains/jediterm/pull/311），Apple 的 Terminal.app 直接让 DCS 序列泄露到输出中（https://github.com/dankamongmen/notcurses/blob/e8b4c7958ace55c4b09b5337a0ed6031f5eb8aba/src/lib/termdesc.c#L1052-L1061）。我并非专门针对任何人，只是想说明这些问题存在，终端模拟很难做对。↩（https://mitchellh.com/writing/libghostty-is-coming#user-content-fnref-4） 5. 很多通用终端模拟器也曾出错，包括 Ghostty 在 9 个月前（https://github.com/ghostty-org/ghostty/pull/5033）。↩（https://mitchellh.com/writing/libghostty-is-coming#user-content-fnref-5）