ハクソク

世界を動かす技術を、日本語で。

「Libghostty」がやってくる

244日前原文(mitchellh.com)

概要

libghosttyは、あらゆるアプリケーションに組み込める高速・高機能なターミナルエミュレータライブラリの実現を目指すプロジェクト。 最初の提供コンポーネントはlibghostty-vtで、依存ゼロのターミナルシーケンス解析APIを持つ。 現時点ではZig APIでテスト可能、C APIも近日公開予定。 libghosttyは多くの現場で発生するターミナルエミュレーション問題を、再利用可能な形で根本解決する狙い。 開発者からのフィードバックを募集しており、今後多機能化・多プラットフォーム対応も計画中。

libghostty構想と背景

  • libghostty は、どんなアプリケーションにも 高速・高機能なターミナルエミュレータ を埋め込むためのライブラリ構想
  • ターミナルエミュレータは Ghostty, Kitty, iTerm2 などの専用アプリだけでなく、 tmux, zellij のようなマルチプレクサやエディタ組み込みでも多数実装
  • 多くのWebサービスやアプリも、ログ表示やコマンド出力のために 簡易的なターミナルエミュレーション を独自実装
  • これらの多くは アドホックな一度きりの実装 で、共通ライブラリや再利用可能なコードベースを使っていない現状
  • ターミナルエミュレーションは 一見単純だが、実際は複雑でバグやパフォーマンス問題が多発 しやすい領域

libghostty-vtの特徴と狙い

  • libghostty-vt は、 依存ゼロ（libcすら不要） のターミナルシーケンス解析・状態管理APIを提供
  • カーソル位置、スタイル、テキスト折返し などの状態管理や、 ターミナルシーケンス解析 が主な機能
  • Ghostty本体のコアロジック を抽出し、 SIMD最適化パース、高度なUnicode対応、メモリ効率、堅牢なテスト済みコード を継承
  • Kitty Graphics ProtocolやTmux Control Mode など、現代的な機能にも高い互換性
  • macOS・Linux（x86_64/aarch64） を初期ターゲットとし、将来的に WindowsやWASM、組み込みデバイス にも対応予定

libghosttyの長期展望

  • libghostty-vt は出発点であり、今後は 入力処理（キーボードエンコード）、GPUレンダリング（OpenGL/Metal）、GTKウィジェットやSwiftフレームワーク など、機能ごとに分割したライブラリ群を提供予定
  • 依存性・コードサイズ・保守コスト最小化 を重視した設計方針
  • 安定化後はさらに多様な機能追加 を継続

現状のステータスと今後

  • Zigモジュールとしてlibghostty-vtを公開、最小限のサンプルプログラムも提供
  • C APIは現在開発中、近日中にテスト可能になる見込み
  • API設計のフィードバックを広く募集、実際の利用者の意見を重視した開発体制
  • libghosttyのバージョン管理はGhostty本体と分離、今後6ヶ月以内にタグ付きバージョンのリリースを目指す
  • "alpha"段階であり、APIの安定性は未保証 だが、コアロジックは実運用で実証済み

開発者・コミュニティへの呼びかけ

  • libghosttyのAPI設計に参加・意見提供してくれる開発者を募集中
  • Ghostty Discordでの議論・コラボレーション を推奨、メールでも連絡可能
  • API自体はα品質 だが、コアロジックは商用利用実績もあり安定

libghosttyの意義と今後

  • Ghostty本体の安定化と並行して、libghosttyの開発が本格化
  • libghosttyの普及により、Ghostty自体もより高機能・安定化
  • アプリやサービスのターミナルエミュレーション問題を根本から解決するインフラ提供 が最終目標

参考

  • 多くの既存実装やWebサービスでの問題例 （Jeditermのバグ、Apple Terminal.appのDCSシーケンス処理不備等）
  • Xterm.jsやlibvteのような既存共有ライブラリも一部利用されているが、カバー範囲は限定的
  • ターミナルエミュレーションは予想以上に難易度が高い分野

まとめ libghosttyは、あらゆるアプリケーションに 正確・高速・再利用可能なターミナルエミュレーション機能 を提供するための根本的なソリューション。今後の進化・多機能化に期待。

Hackerたちの意見

これをずっと注目してるんだけど、Neovimベースのターミナルでテキストリフロー（編集：スクロールバックも含む）が解決できることを期待してるんだ。Ghosttyがターミナルの世界にもたらしている革新が大好き。

└

自分をNeovimターミナルのパワーユーザーだと思う？ しばらく前に、ワークフローを逆転させようとしたんだ（tmuxがNeovimを動かすのから、Neovimがターミナルを動かす方向に）。特定のファイルに対してバッファを一つだけ開いておく方が楽だと思ったからなんだけど、別のNeovimインスタンスの別のペインで既に開いてるファイルを開こうとして気づくのが面倒で。テストしてた時、libghosttyに切り替えたら解決できそうなテキストリフローの問題には気づかなかったな。むしろ、違うパラダイムに慣れるのが大変だった。Neovimの埋め込みターミナルに全力投球してる人の話をもっと聞いてみたいな（libghosttyがどう改善するかも含めて）。

これめっちゃクールだね！iOSやAndroidにまで拡張できる本当にオムニプラットフォームなターミナルエミュレーターがあるなんて素晴らしい。ちなみに、GhosttyがZigで書かれてるって知らなかった、すごい！普段使うZigのものはこれが初めてだよ。リポジトリの構造がまるでGolangのレイアウトみたいで面白い、笑。

└

（ゴーのレイアウトには見えないけど）それがいいんだよね。pkg/ src/ とかはゴーのディレクトリとしては良くないから。

この人が数十億ドルの会社を設立して公開して売却した後、またハッキングに戻るって、伝説だね。

└

しかも、Unixの技術スタックの中でも一番オタクっぽいttyソフトウェアにハッキングしてるし。

└

Ghostty大好きで毎日使ってるけど、Mitchell Hashimotoが作ったってことを見逃してた！すごくクールだね。

└

100% 伝説！Ghostty大好きだよ、ちなみに :)

└

橋本さんは本当に魔法使いみたいな人だけど、彼の一番すごいところは、システムやインターフェースを最大限に組み合わせやすく、最小限の絡み合いで抽象化する能力だと思う。リッチ・ヒッキーの「シンプルを簡単に」の哲学を体現してるみたい。ソフトウェアシステムを、正しく予測可能に動くように設計してる感じ。あと、初めてGhosttyを試してみたんだけど、iTerm2とZsh/Powerlevel10kテーマを使ってると、コマンドを実行してから表示されるまでにすごく短いけど感じられる遅延があった。ghosttyでは実際に瞬時に感じるよ。

Mitchellの開発者体験への情熱と細部へのこだわりは、俺には理解できない。初めてVagrantを使った時（2011年、サンタモニカ、カリフォルニア）の衝撃は昨日のことのように覚えてる。iTerm2を捨てるなんて思いもしなかったけど、Ghosttyが出た時にインストールして、すっかりハマっちゃった。

今は毎日ghostty使ってるよ。最近切り替えたんだけど、macOSではcaps lockをcmdにリマップできて、cmd+cもちゃんと動く。その他は全部素晴らしいし、デフォルト設定も良い感じ。グルーヴボックスのライトテーマもめっちゃいいよ。Zigで書かれてるってのもすごいし、Zigが準備できてるか疑問に思ったら、ghosttyがその答えだね。戻る気は全然しない。最高の体験だよ。ヒント：ghosttyのフローをエアロスペースと組み合わせると、Macでのキーボードだけの体験がほぼ完璧になるよ。

これを使ってEmacsのvtermをモダナイズしたいんだ。ターミナルのカーソルとEmacsのポイントを同期できて、行を分割せずにそのまま保てたら最高なんだけど…。

tmuxシムアプリを実装するのはどれくらい簡単かな？行番号をpty自体にネイティブで持たせるだけなんだけど。tmuxのコピーモードはすでに素晴らしいけど、唯一の不満は行番号がないこと。これのスクリプトは結構良いけど、バグが頻繁に出るし、フルスクリーンモード（2ペイン）では動かないんだ。根本的な問題は、行番号をミラーリングするためだけに新しいtmuxペインを割り当ててること。できれば同じペインで同期できたらいいのに。neovimにパイプするのは、neovimとzellijの両方でできるオプションだけど、zellijは色が失われるし、neovimがこの問題のベストな解決策かもしれない。でも、毎回行番号をオン/オフするのを覚えておくのは面倒だし、個人的には一時的なペインが好きなんだ。役割の分担って感じかな。要するに、こういう標準があれば問題が簡単に解決できるのかな？ターミナルについての理解からすると、基盤のptyを解析して、ラッパーシム内にスクロールバックバッファを保持し、行番号のオン/オフを動的に調整できる必要があると思う。こういう翻訳をやる場合、どれくらい「漏れ」が出るんだろう？結局は中間層でロジックを再実装することになるのかな？「無料」でptyからの入出力の翻訳ができるとしても。TUIツールをもっと詳しく見ようとしてるけど、これが本当に気になってる。VTプロトコルがどれだけひどいかを考えると、状態遷移の解析は正しくできても、開発者は何年もかけて追加された小さな癖を全部学ばなきゃいけないよね？（誰かが間違った同等性を持ち出さないように、これはc++のような言語でも同じじゃない。今でも小さな癖を学んでるけど、ちゃんとした堅牢なコードを作るために全てを学ぶ必要はない。VTプロトコルのようなものは同じじゃない気がする。だから、ある程度の学習は必要だと分かってるけど、どれだけ構造化された開発者体験になるのか気になるな。）

これを楽しみにしてる！Rubyで自分のエディタを書いてるんだけど、ターミナル入力を解析するライブラリがないから、自分でkittyキーボードプロトコルのパーサーを書かなきゃいけなくて、ルックアップテーブルを手動で作るのが本当に面倒。既存のTUIフレームワークを使うのはあんまり好きじゃないんだ。どれもkittyプロトコルを実装してないから。* https://sw.kovidgoyal.net/kitty/keyboard-protocol/#

最近VS CodeをやめてNeovimに切り替えたんだけど、Ghosttyのおかげで移行が成功したよ。Macユーザーとしてはcmdキーをたくさんのショートカットで使うから、初めからちゃんと動いてくれて、変なエスケープシーケンスを送る必要もなかった。

すごい機能の互換性、たとえばKitty Graphics ProtocolやTmux Control Modeの解析など、もっと色々。おおおお！！！ > https://github.com/ghostty-org/ghostty/issues/1935 あああ...（ghosttyはTmux Control Modeのものを解析できるけど、実際にはフル機能を実装してないんだ。iTerm2への依存はまだ続いてる…）

└

GhosttyはTmuxのコントロールモードを解析することができるんだ（このブログ記事はlibghostty-vtについてのもの）。でも、GhosttyのGUIはそれをGUI要素にマッピングする機能が欠けてるんだよね。でも、Ghosttyは今のところTmuxのコントロールモードを理解してるよ。