Ghostel.el - libghosttyベースのEmacsターミナルエミュレーター
(dakra.github.io)- Ghostelは、Ghosttyと同じ
libghostty-vtエンジンを使用するEmacsターミナルエミュレーターで、Zigネイティブモジュールがターミナル状態・レンダリング・ローカルPTY入出力を担当し、Elispがキーマップ・バッファ・コマンド・リモートプロセスを管理する - Kittyキーボード／グラフィックプロトコル、OSC 8ハイパーリンク、OSC 4/10/11カラー問い合わせ、DEC 2026同期出力と5種類の入力モードに対応し、ローカルのbash・zsh・fish・nushellにはシェル統合を自動適用する
- Emacs 28.1以降とmacOS・Linux・FreeBSD・ネイティブWindowsをサポートし、初回利用時にプラットフォーム別の事前ビルド済みモジュールを自動でダウンロードできるため、一般的なインストールではZigツールチェーンは不要
- Apple M4 MaxとEmacs 32.0.50で1MB出力を処理したベンチマークでは、通常のASCIIでGhostel 75MB/s、vterm 18MB/s、eat 6.2MB/sを記録し、ネイティブPTYは10MBの
cat処理を約110msで吸収した - TRAMPリモートターミナル、パスワード入力保護、Kittyインライン画像、コンパイル・Eshell・Comint・Evil・入力メソッド連携まで提供するが、リモート先と画像処理にはプラットフォームおよびプロトコル上の制約がある
構成とインストール
- Ghostelはemacs-libvtermの2層設計に着想を得ているが、libvtermの代わりにGhosttyのモダンなVTエンジンを使用する
- Zigモジュールはターミナル状態、レンダリング、キーエンコーディング、ローカルPTYとバックグラウンド読み取りを処理する
- Elispはキーマップ、バッファ、コマンド、プロジェクト連携、TRAMPリモートプロセスを担当する
- 要件は、動的モジュールをサポートするEmacs 28.1以降と、macOS・Linux・FreeBSDまたはネイティブWindows
- 事前ビルド済みバイナリは、
aarch64-macos、x86_64-macos、x86_64-linux、aarch64-linux、x86_64-freebsd、x86_64-windows、aarch64-windows向けに提供される - ほかのプラットフォームやソースビルドにはZig 0.15.2が必要
- 事前ビルド済みバイナリは、
- MELPA、Emacs 30以降の
use-package :vc、:load-path、手動のrequire方式でインストールでき、M-x ghostelでターミナルを開く - ネイティブモジュールがない場合、
ghostel-module-auto-install設定に従ってダウンロードまたはソースコンパイルを提案するM-x ghostel-download-moduleは最低限サポートされるバイナリを取得し、接頭引数を付けるとリリースタグを選択できるM-x ghostel-module-compileはzig buildでモジュールをビルドする- パッケージディレクトリが再インストールされる可能性がある場合は、
ghostel-module-directoryを別の場所に指定できる
- ソースビルドには生成済みの
vendor/emacs-module.hが含まれるため、通常はローカルのEmacsヘッダーは不要で、EMACS_INCLUDE_DIRまたはEMACS_BIN_DIRでヘッダー位置を変更できる- コンパイル済みの
xterm-ghosttyterminfoはetc/terminfo/に含まれ、BSDとncursesで移植可能な形式
- コンパイル済みの
Windowsサポート
- ネイティブWindows EmacsではConPTYでローカルターミナルを実行し、モジュールDLLのアーキテクチャはWindowsではなくEmacsのアーキテクチャと一致している必要がある
- 事前ビルド済みモジュールと一緒に
conpty.dll、OpenConsole.exeのサポートファイルをダウンロードし、これらのファイルがない場合はWindows内蔵のConPTY APIにフォールバックする - 静的CRTなどの特殊なカスタムEmacsビルドはベストエフォート方式でのみサポートする
- WindowsのTRAMPターミナルはPOSIXリモート先のみサポートし、PTYはリモートホスト上に存在する。動的なウィンドウサイズ変更は現時点ではサポートしない
5種類の入力モード
- デフォルトのsemi-charモードはほとんどのキーをターミナルへ送る一方、
C-c、C-x、C-u、C-h、M-x、M-:、C-\のような例外はEmacs側に残す- 割り込み・中断・EOF送信、bracketed paste、スクロールバック削除、プロンプトおよびハイパーリンク移動のためのキーを提供する
- charモードはすべてのキーをターミナルへ送るため、自前で
C-x、M-x、C-hを使うTUIに適しており、M-RETだけが脱出キーとして残る - Emacsモードはターミナル出力を受け続けながらバッファを読み取り専用に変え、
isearch、occur、マークとコピーなど標準のEmacsナビゲーションを可能にする- 通常の入力はシェルへ渡されず、意図的な
C-y貼り付けだけがbracketed pasteとして送信される
- 通常の入力はシェルへ渡されず、意図的な
- copyモードはターミナル更新を止め、安定して選択・移動・コピーできるようにする
- コピーしたテキストでは、ソフトラップによって生じた改行を除去する
- デフォルトの
ghostel-readonly-fast-exit=tでは、文字入力またはコピー後に自動で通常のターミナルセッションへ戻る
- lineモードはキーをシェルへ即座に送らず、Emacsバッファで1行を編集してから
RETでまとめて送信する- 非同期出力や新しいプロンプトが到着しても、入力中の内容をスナップショットとして保持してから再挿入する
- OSC 133があればプロンプト境界を使用し、なければ
ghostel-prompt-regexpで境界を探す - 全画面TUIが開始されるとsemi-charモードに切り替わり、TUI終了後にlineモードへ戻る
TABはcomint補完と、任意でbash programmable completionを使用する
- マウスドラッグ、複数クリック、マーク有効化、
isearchまたはconsult-lineでライブ入力位置から外れた場合、デフォルトではcopyモードへ切り替えて選択と位置を保護する- TUIがDECマウス追跡を有効にしている場合、入力モードではマウスイベントをそのプログラムへ渡す
ghostel-mouse-drag-input-mode、ghostel-mark-activation-input-mode、ghostel-point-leave-input-modeで切り替え動作を変更できる
ターミナル機能とレンダリング
- libghostty-vtを通じて、完全なVTエミュレーション、256色と24ビットカラー、alternate screen、複数の下線スタイルと色、太字・斜体・淡色・取り消し線・反転、4種類のカーソル形状と点滅をサポートする
- デフォルトの
TERM=xterm-ghosttyと同梱terminfoは、DEC 2026同期出力、Kittyキーボード、true color、色付き下線、フォーカス報告などの機能をアプリケーションへ知らせる- OSC 4/10/11問い合わせにより、TUIはEmacsフェイスの色からパレットと前景・背景色を取得できる
- OSC 52クリップボードはサポートするが、デフォルトでは無効なため、同梱terminfoでは
Ms機能を広告しない
- デフォルトのスクロールバックは5MB、約5,000行で、Emacsバッファとして実体化されるため、
isearchとconsult-lineで検索できる - OSC 8ハイパーリンクのほか、通常のHTTP・HTTPS URLと
/path/file.el:42形式のファイルパスを検出し、クリック可能なリンクにする - GhosttyキーエンコーダーとKittyキーボードプロトコル、SGRマウスイベント、DEC 1004フォーカスイベント、ファイルパスおよびテキストのドラッグ＆ドロップをサポートする
- レンダラーは変更のない行をスキップし、タイマーで更新をバッチ化し、フレームレートを適応的に調整する
- キー入力直後に到着したPTYエコーは、デフォルトの33msタイマーを迂回して即座にレンダリングする
ghostel-sync-themeはEmacsテーマに合わせてパレットを再同期する
- 16個のANSI色は
term-color-*を継承するEmacsフェイスであり、ghostel-defaultでターミナル専用のフォント・サイズ・前景・背景を設定できる
シェル統合と Emacs 呼び出し
- bash・zsh・fish・nushell には OSC 7 ディレクトリ追跡、OSC 133 プロンプト移動、OSC 2 タイトル追跡と
ghostel_cmdを自動設定する- nushell 自体のシェル統合が OSC 7・133・2 を提供し、
ghostel.nuはghostel_cmdと outbound SSH terminfo ラッパーを追加する - macOS 内蔵の bash 3.2 は自動注入に使う
ENVを無視するため、新しい bash を使うかghostel.bashを手動で読み込む必要がある
- nushell 自体のシェル統合が OSC 7・133・2 を提供し、
- シェルから Elisp を呼び出す
ghostel_cmdは専用の OSC 52;e 拡張を使い、ghostel-eval-cmdsの許可リストにある関数だけを実行する- デフォルトで許可される関数は
find-file、find-file-other-window、dired、dired-other-window、message
- デフォルトで許可される関数は
- Emacs ブックマークはターミナルの作業ディレクトリとバッファ名を保存する
- 既存バッファがあれば再利用し、なければ保存されたディレクトリで新しいシェルを起動する
- スクロールバックとセッション内容は保存しない
パスワード・クリップボード・通知
sudo、ssh、gpg、passwdなどのパスワードプロンプトを検出するとread-passwdを開き、回答を PTY に直接送るため、入力はview-lossage、最近のキーリング、キーボードマクロに残らない- ローカルでは canonical モードと echo の無効化を
tcgetattrで確認する - リモートシェルでのみ正規表現による代替検出を使い、ローカルの raw-mode TUI における誤検知を減らす
- 送信後、パスワード文字列は直ちに
clear-string処理する ghostel-password-prompt-functionsに auth-source、KeePass、pass などの供給元を追加できる
- ローカルでは canonical モードと echo の無効化を
- OSC 52 を明示的に有効化すると、リモートプログラムが Emacs kill ring とシステムクリップボードを設定でき、貼り付けは bracketed paste で送信する
- OSC 9 と OSC 777 の通知は
ghostel-notification-functionに渡す- デフォルトハンドラーは、インストールされていれば alert を使い、なければ echo 領域の
messageにフォールバックする
- デフォルトハンドラーは、インストールされていれば alert を使い、なければ echo 領域の
- OSC 9;4 の進捗は
remove、set、error、indeterminate、pause状態と 0〜100 の値を渡す- デフォルトのテキスト表示器と spinner.el ベースのアニメーション表示器を提供する
Kitty インライン画像
- Kitty graphics protocol の直接配置と U+10EEEE Unicode-placeholder 配置をサポートし、
timg、kitty +kitten icat、yaziなどの画像をレンダリングする - PNG は同梱の stb デコーダーで処理し、RGB・RGBA・Gray・GrayAlpha データはネイティブモジュールで PPM に変換するため、ImageMagick は不要
- CSI 14・16・18
tのサイズ問い合わせに応答し、ghostel-cell-pixel-scaleで物理ピクセル比を設定できる - 画像処理には次の制約がある
- アルファチャンネルは合成せず削除するため、半透明のエッジには適さない
- Kitty source-rect の部分切り抜きはサポートせず、明示的なエラーを返す
- 同じバッファ内の複数の仮想配置は 1 つのレンダリングを共有し、直近の送信が優先される
- デフォルトでは inline base64 のみ許可し、ファイル・一時ファイル・共有メモリ媒体は安全のため明示的に有効化する必要がある
- ターミナルごとのデフォルトのグラフィック保存上限は 320MiB
TRAMP とリモート terminfo
default-directoryが TRAMP パスなら、その POSIX ホストでシェルを実行し、SSH 系 TRAMP 方式やdockerなどのシェルをghostel-tramp-shellsで指定できるlogin-shellはgetent passwdでリモートユーザーのログインシェルを検出する- OSC 7 ディレクトリ追跡は既存の TRAMP の方式・ユーザー・マルチホップ接頭辞を保持する
- Windows のリモート対象は、この POSIX シェル・tty 経路ではサポートしない
- リモートシェル統合はデフォルトでは注入せず、2 つの方式を提供する
ghostel-tramp-shell-integration=tで一時スクリプトを転送し、終了時にクリーンアップする- 永続ホストには
etc/shell/スクリプトと、任意で terminfo を直接インストールできる
- リモートに
xterm-ghosttyterminfo がないとターミナルを開くのに失敗することがあり、ghostel-ssh-install-terminfoがインストールを処理する- TRAMP 実行では既存接続で一時ディレクトリに terminfo を転送し、終了時に削除する
- ローカル Ghostel から実行した
sshはssh -Gで対象を正規化してキャッシュを参照し、必要なら 1 回の追加接続でtic -x -を実行する - ローカル terminfo のハッシュがキャッシュキーに含まれるため libghostty 更新時に自動で無効化されるが、リモート側で別途変更された terminfo は検出できない
ssh HOST cmd、ホストのないオプション呼び出し、ローカルにinfocmpがない場合はインストールをスキップする
- リモートホストを変更したくない場合は自動インストールをオフにして自分で terminfo をインストールでき、
ghostel-termをxterm-256colorに変えれば関連設定は不要になるが、Ghostty 専用の 同期出力高速経路も失われる
Emacs 拡張機能
- evil-ghostel は Evil の insert・normal 状態とターミナルカーソルを同期する
- 移動、挿入、削除、変更、置換、bracketed paste、readline undo と状態別カーソル形状をサポートする
- alternate screen の vim・less・htop には影響しない
ghostel-compileは実際の PTY でコマンドを実行しつつ、compilation-mode形式のヘッダー・フッター・エラー強調・next-errorナビゲーションを提供する- デフォルトは読み取り専用のナビゲーションで、前置引数を与えると対話的入力を渡す
- 実行中でも
C-c C-jとC-c C-eまたはC-c C-tで対話的入力とコンパイルナビゲーションを切り替えられる ghostel-compile-global-modeはcompile、recompile、project-compileとcompilation-start呼び出しを Ghostel に送るgrep-modeはデフォルトで既存実装を維持する
ghostel-eshell-visual-command-modeは Eshell の vim・htop・less のような 視覚コマンド（visual command） をterm-modeではなく専用の Ghostel バッファで実行するghostel-comint-modeは comint 出力ストリームをlibghostty-vtで処理し、true color、多様な下線、OSC 8 リンク、OSC 7 ディレクトリ更新を提供する- 完全なターミナルではないため、カーソル配置、alternate screen、全画面再描画は捨て、
htopやlessには適さない
- 完全なターミナルではないため、カーソル配置、alternate screen、全画面再描画は捨て、
ghostel-ime-modeはハングルなど、バッファに直接文字を挿入する Elisp 入力メソッドの結果を消してから UTF-8 で PTY に渡す- Quail の合成中はレンダリングを遅らせ、バッファが合成文字列を上書きしないようにする
パフォーマンス
- Apple M4 MaxとEmacs 32.0.50で、実プロセスのパイプに1MBを送り、約1,000行のスクロールバックを保持した結果は次のとおり
- 通常のASCII: Ghostel 75MB/s、リンク検出無効のGhostel 76MB/s、vterm 18MB/s、eat 6.2MB/s、内蔵term 7.2MB/s
- URLが多い出力: Ghostel 36MB/s、リンク検出無効のGhostel 78MB/s、vterm 15MB/s、eat 4.5MB/s、term 5.9MB/s
- URL・ファイルパス検出は再描画パスの外にある統合タイマーで実行されるため、通常の出力ではコストがほとんどないが、リンクが密集した出力ではスループットが約半分に低下する
- 公平な比較のため、上記の数値はEmacsプロセス経路を使用しており、デフォルトのローカルネイティブPTYではZigのバックグラウンドスレッドが出力を読み取るため、継続的な大容量ダンプで約2倍高速になる
- 10MBファイルを
catした5回の中央値は、ネイティブGhostelが約110ms、Emacs PTY Ghostelが約220ms、vtermが約550ms、eatが約1.8秒- vtermとeatは転送中にEmacsのメインスレッドを同期的に占有するが、GhostelのネイティブPTYはバックグラウンドでパースするため、UIは引き続き応答する
M-x ghostel-debug-typing-latencyは、キーごとのPTY・レンダリング・全体遅延の最小値、中央値、p99、最大値を測定する
vterm・eatとの違い
- vtermはCベースのlibvtermネイティブモジュールを使用し、eatは純粋なElispで書かれていてビルドなしで移植できる代わりにスループットは低い
- GhostelだけがKittyキーボード・グラフィックス、5種類の下線、OSC 8、OSC 4/10/11、OSC 9・777通知、OSC 9;4進捗率、DEC 2026をすべてサポートする
- eatはSixel画像をサポートするがKitty画像はサポートせず、vtermはどちらの画像プロトコルもサポートしない
- GhostelとeatはSGRマウスイベントをTUIに渡すが、vtermはクリックをEmacsのポイント移動に使う
- Ghostelとeatはlineモードを提供するが、vtermは提供しない
- Ghostelは出力が止まるcopyモードと、出力が続くEmacsモードの両方を提供する
- vtermは停止型のcopyモードを提供し、eatの読み取り専用Emacsモードは更新され続ける
- Ghostelはシェル統合を自動注入するが、vtermとeatでは手動でスクリプトを読み込む必要がある
- パスワードプロンプトはGhostelが自動検出し、eatは手動送信コマンドのみを提供し、vtermは入力を別途インターセプトしない
内部アーキテクチャ
- ローカルバッファはデフォルトでZigがPTYを開いて子プロセスを生成した後、バックグラウンドスレッドで出力を
libghostty-vtへ渡す- OSCコールバックや再描画が必要な場合は、LispイベントをEmacsのパイプへ送り、
ghostel--events-filterが処理する - 大量出力がEmacsプロセスフィルターをバイト単位で通過することはない
- OSCコールバックや再描画が必要な場合は、LispイベントをEmacsのパイプへ送り、
- TRAMPバッファはリモート生成とファイルハンドラーを維持するため、Emacsプロセスが出力を受け取り、同じターミナルモデルへ同期的に渡す
- キー入力はlibghosttyエンコーダーを経由してPTYへ即座に書き込まれ、出力はVTパーサーと無効化ステップを経て、対話的なエコーであれば即時に、そうでなければ統合タイマーで
Renderer.zigが変更された行を更新する - ターミナルレンダリングは、行の置換、全体再描画、サイズ変更とreflow、スクロールバックの追加・削除によってEmacsバッファを修正するため、レンダラーがポイント・マーク・ウィンドウ位置の保持を担う
- Elispは、入力後にライブビューポートへ移動するか、各モードでナビゲーション状態を維持するかといったポリシーとユーザーの意図を決定する
- レンダラーの変化をElispのredraw前後のヒューリスティックで補正すると、ユーザーのスクロール、redisplay補正、サイズ変更、コンテンツ再書き込みの原因を区別しにくくなるため、避けるべき
テストとライセンス
- テストはERTベースで、ElispテストはZigモジュールなしで実行でき、
nativeタグ付きテストにはビルド済みモジュールが必要- Zig単体テスト、全体テスト、Evil拡張テスト、クイックベンチマーク用のMakefileターゲットを提供する
- バグや機能リクエスト、プルリクエストはGitHubリポジトリで受け付けており、レンダリング問題には再現コマンド・escape sequence・Emacsバージョン・プラットフォーム情報が必要
M-x ghostel-debug-infoで診断イベントを収集できる- GhostelはGNU GPL v3以降で配布される自由ソフトウェア
3件のコメント
日本語入力はできないように思います。
Ctrl-\を押すと入力方式は日本語に切り替わるようですが、実際には英字入力しかできないようですね。少し残念です。
Lobste.rs のコメント
ghostel-projectコマンドでそのプロジェクトに紐づいた Ghostel を使っているプロジェクト用のインスタンスがすでにあれば、そのインスタンスにそのまま切り替わるので、ターミナル間の行き来が非常に速い
vtermには不満な点もあるが、ターミナル内でもエディタのコマンドをそのまま使える点は本当に良いEmacs でターミナルエミュレータの話になると、よく
cd/mv/ls/cp/rm/mkdr/...の代わりにdired、ビルドコマンドの代わりにcompileを使えばいいのに、なぜ必要なのかという反応が返ってくる。だが複雑な作業をしないとしても、ターミナルのほうがより慣れていて柔軟に感じる特に Doom Emacs でターミナルへの依存度を下げる方法を案内するガイドがあるなら、試してみたい。高度な設定でプロジェクトを素早く行き来する様子はいつ見ても印象的だ
vtermのような環境で壊れたり、行サイズ計算の問題でjjの画面が時々完全に崩れたりして、もどかしい結局、横に Ghostty を開いておくことになるが、いつかすべてのツールが Emacs 内で正しく動くようになってほしい
eshellをかなり使っているeat-eshellを使うと、ビルドツールや Podman CLI のようにターミナルエミュレーションを必要とするプログラムや TUI アプリケーションもeshellバッファ内でそのまま動作するため、eshellをよく使う人にとっては状況を一変させる機能だeshellを別に使う用途が何なのか気になる。eshellをあまり使っていないので、その目的を見落としているように感じることがよくあるHacker Newsのコメント
Ghostelのメンテナーです。baokaolaと来週Show HNを投稿するつもりでしたが、誰かが先にリンクを投稿していました
ざっと見るならGitHubリポジトリのほうが便利です: https://github.com/dakra/ghostel
Ghostelはlibghostty-vtベースのEmacsターミナルエミュレータで、vtermやeatとの機能比較はhttps://dakra.github.io/ghostel/#ghostel-vs-vtermで見られます。性能と正確性を画像で比較した資料もあります: https://gist.github.com/dakra/4a0b76ebcf5d52338e134864378465...
個人的には、vterm/eatだけでなくkittyやGhosttyのような外部ターミナルまで置き換えました。ターミナルのテキストを普通のEmacsバッファのように扱えると、他のターミナルにはない数多くの拡張可能性が開けます。スクロールバックを検索し、その後キーボードだけで移動して段落を選択・コピーするような簡単な作業も、Emacsユーザーにははるかに自然で高速です
Ghostelを使っても外部ターミナルを残すなら、機能不足が理由なのか、それとも一部のプロセスをEmacsの外で動かしたいのか気になります。GitHubでも積極的に対応しているので、問題があればイシューを開いてください
f1をセミ文字モードとコピーモードの切り替えに割り当てていて、コマンドを実行する前に「Emacsが落ちたり強制終了しても大丈夫か？」と考えています。大丈夫でなければ普通のターミナルで実行しますGhostelはそこまで同じレベルでは統合されておらず、evil-ghostel-modeのような拡張にも限界があります。これを改善する計画があるのか、構造的に受け入れざるを得ない制約なのか気になりますし、eat-eshell-modeに相当する機能ができれば素晴らしいと思います
タイトルにはEmacsを入れるべきです。一般的なターミナルエミュレータとEmacs用ターミナルエミュレータは別物です
.elはEmacs Lispファイル拡張子です最近vtermからGhostelに乗り換えましたが、全体的にはるかに優れています。毎フレーム端末全体を更新する派手なTUIアプリもきちんと動くほど目に見えて速く、入力処理もより安定していて、ELisp APIも良いです
ただ、ターミナルをきれいに消去できず現在のプロンプトの上にゴミが残ったり、完全に固まってバッファを閉じて再起動しなければならなかったこともあります。日常利用には十分で将来性も明るいですが、成熟した製品になるにはバグ修正と仕上げ作業がまだ必要です
画面上部にゴミが残る現象はhttps://github.com/dakra/ghostel/issues/495かもしれず、最新版では修正されていますが、別のバグの可能性もあります。難しいのは、libghostty-vtの内部データをEmacsバッファへ複製しつつ必要な部分だけ置き換えることです。これを広範囲に検証するプロパティベーステストがありますが、ときどき問題を取り逃がします
現在の最新リリースではライフサイクル処理が改善されており、一部の問題はそれで一緒に解決しているかもしれません。まだ初期段階なので、徐々に磨いていきたいと思っています
異なる入力モードを効率よく使う実例があるとよいですね。ターミナルはすべてのキー入力を欲しがり、エディタも独自コマンドにキーを使いたがるため、エディタ内蔵ターミナルにはキーボードの所有権を切り替えるモードが必須です
Neovimの
:termにはモードが2つしかないのに、Ghostelにはなぜ5つもあるのかを理解しないと、過剰設計だと誤解しやすいです。実際にはより多くの問題を解決するために複雑になっており、追加モードはnvimが扱わない作業のための任意のツールです。ただ、その利点を実運用でどう効率的に活かすかはまだ十分明確ではありませんvtermの使用に苦労していたところGhostelを試してみたら素晴らしく、メインのターミナルになるかもしれないと思っています
1か月以上使っていますが、Codexの要約に出てきたコード参照をクリックしてEmacsバッファで直接開ける機能が特に気に入っています
ghostel-previous-hyperlinkやghostel-next-hyperlinkで最近表示されたハイパーリンク間をすばやく移動できますrepeat-modeマップも入るので、出力にURLやファイルリンクが3つあるなら
C-c C-p p p RETだけで最初のリンクを開けて、よく使っていますGhostelとClaude Codeの統合のおかげでEmacsの使用量が大きく増え、今ではEmacsが作業の中央ハブになっています
いくつかのウィンドウにターミナルを10個ほど開くと、Ghosttyがほぼ毎晩クラッシュしていました。そのためGhosttyをまともに使えず、毎日使うツールの中に組み込みたいとも思いません
数百万ファイルあるファイルシステム上で、できるだけ多くのシェルに
ls -lRも実行しましたが、問題やクラッシュはありませんでした。ここ数か月、毎日一日中かなり激しく使っていますが、クラッシュや怪しい挙動を見たことはありません特定のGhosttyバージョンのバグか、GPUドライバのような別ソフトウェアとの特殊な相互作用である可能性が高そうです。こちらではNVIDIA GPUを使っています
「ネイティブモジュールは事前ビルド済みバイナリで、初回使用時に自動ダウンロードされる」とありますが、なぜ配布パッケージに含めないのか気になります
Emacsネイティブモジュールを使う人気パッケージのjinxも、vtermのように初回使用時にコンパイルする方式を提供しています。したがって、Emacsパッケージでユーザーフレンドリーなインストールを実現するには、現実的には初回実行時にダウンロードまたはコンパイルする方法しかありません