Ghostty 1.0.1
2024 年 12 月 31 日にリリースされた Ghostty 1.0.1 のリリースノート。
-
GHSA-5hcq-3j4q-4v6p。Ghostty がウィンドウタイトルシーケンスを不適切に扱い、任意のコード実行につながりうる(ユーザー操作が必要)セキュリティ脆弱性を修正しました。
-
GHSA-hfg5-8q2c-crhc。
write_*_filekeybind アクションで作成されるファイルは、以前は0644モードがデフォルトで、どのローカルユーザーでもファイルを読めました。権限のないアクセスを防ぐため、ファイルは現在0600モードがデフォルトです。
PR:#3460
空ではない設定ファイルが見つからない場合、Ghostty は起動時に既定の設定ファイルを作成するようになりました。ゼロ設定の哲学 に沿って、既定の設定ファイルにはコメントのみがありますが、そのコメントはファイルの場所、構文、ドキュメントをユーザーに教える役に立ちます。
1.0.0 リリースでは、設定ファイルの場所、編集方法、利用可能なオプションについて大きな混乱がありました。この変更は、Ghostty の設定方法をユーザーが理解しやすくすることを意図しています。
PR:#4115(CoreText)、#3837(Freetype)
Ghostty は macOS と Linux の両方でビットマップフォントをサポートするようになりました。ビットマップフォントは truetype 形式である必要は変わらずありますが、アウトラインの代わりに各グリフのビットマップを含めることができます。
PR:#4004
「Settings」メニューオプション(open_config keybind アクション)がいくつもの点で改善されました。
まず、Ghostty は存在する場合、開く最初の空でない設定ファイルを見つけるようになりました。以前は AppSupport パスが存在していても、Ghostty は常に XDG 設定パスを先に開いていました。AppSupport パスは XDG パスを上書きするため、混乱の原因になっていました。現在は AppSupport パスが存在すればそこを開き、なければ XDG パスを開きます。
第二に、Ghostty はどちらのパスも存在しない場合、XDG パスよりも AppSupport パスを優先して開くよう正しく扱います。AppSupport パスは macOS 上の他のすべてのパスを上書きするため重要です。
第三に、Ghostty は設定ファイルをテキストエディタで開くために -t 旗標と open を使うようになりました。
Note
将来のアップデートでは、ユーザーが自分の
$EDITORを使って設定ファイルを開けるようになる予定です。また別の将来のアップデートでは、GUI で設定ファイルを編集できるようになる予定です。
- 色の値が省略形の 16 進値を受け付けるようになりました(例:
#ABC)。#4111 confirm-close-surfaceをalwaysに設定すると、ウィンドウを閉じるときに常に確認ダイアログを表示できます。#3700- macOS:Spotlight 検索メタデータに「terminal」キーワードを追加。#3745
- GTK:
window-titlebar-foregroundとwindow-titlebar-backgroundの設定オプションを追加。#3806 - 同梱の iTerm2 配色スキームを e030599a に更新。
- キーにマップされるトリガーを持つキーバインドが、Unicode トリガーではなく翻訳キーとして扱われるようになりました。つまり
cmd+1がcmd+oneに加えて機能するようになり、cmd+.はcmd+periodと同じです。#4147 write_selection_fileが空の内容を書き込むことがありました。#4078- TUI アプリケーション内のハイパーリンクがより安定しました。#3903
- 設定の再読み込みが OSC 10/11/12 を上書きしなくなりました。#3228
scrollback-limit設定が 32 ビットより大きい数値を受け付けるようになりました。#3906- macOS と Linux の両方で問題
background-opacityを修正。#3347 - コマンドライン上で特定の
--font-family=""が設定された場合に起こりうるクラッシュを修正。#4151 - vt:更新された仕様に従い、OSC 10/11/12 に対して mode 2031 DSR レポートを送らなくなりました。#3994
- vt:direct-color 解析のエッジケースを修正。#4216
- bash:シェル統合が
sudoエイリアスとより協調するようになりました。#4080
- macOS:ウィンドウが完全に破棄されないことによるリソースリークを修正。#4128
- macOS:特定の状況で
toggle_visibilityが使えない「ゴーストウィンドウ」を出す問題を修正。#3219 - macOS:Quick Terminal が
focus-follows-mouseで機能するようになりました。#3337 - macOS:全画面時のタイトルバーが Ghostty の他の部分と同様に不透明になりました。#3834
- macOS:全画面を終了すると、正しい背景不透明度を復元するようになりました。#3553
- macOS:読み込み優先度と一致させるため、
open_configアクションは XDG より AppSupport パスを優先するようになりました。#3953 - macOS:テキストエディタが開くよう、
open_configアクションは-t旗標付きのopenを使うようになりました。#3284 - macOS:quick terminal が CPU 100% を消費し、電池を大きく消耗させることがある問題を修正。quick terminal は現在、アイドル時に CPU を消費しません。#4055
- macOS:app bundle に
nvimディレクトリが含まれるようになりました。#3966 - macOS:ヘルプメニュー項目が Ghostty ドキュメントを開くようになりました。#3990
- macOS:blur radius が未設定の場合に、実行時に正しく再読み込みされるようになりました。#3954
- macOS:
$HOMEが書き込み不可だった場合の起動クラッシュを修正。#3949
- GTK:推奨 API が利用できない場合に非推奨の API へフォールバックすることで、古い GTK バージョンで正しいシステムカラースキームを検出。#4035
- GTK:
gtk-titlebar=falseとgtk-tabs-location=hiddenが両方ある場合にウィンドウが壊れる問題を修正。#3178 - GTK:一部の機能の最低 GTK バージョンを誤って検出していたバージョン比較を修正。#3977
- GTK:対応デスクトップ環境のために 1024x1024 アプリアイコンをインストール。#4003
- GTK:
window-decoration=falseとgtk-titlebar=trueの場合のアーティファクト問題を修正。#3999 - GTK:
window-theme=ghosttyのときタブ概要にスタイルが付くようになりました(libadwaita 1.8 が必要)。#3920 - GTK:
gtk-titlebar=falseでもタブ概要が機能します。#3940 - GTK:ちらつきを避けるため、タイトル変更に短い遅延を追加。#3746
- GTK:desktop ファイルに
xdg-terminal-execフィールドを追加。#3853 - GTK:X11 対応のない libgtk に対するビルドをサポート。#3748
- GTK:サーフェスを閉じるときに起こりうるセグフォルトを修正。#3694
- Ghostty のソース tarball は
ghostty-${VERSION}.tar.gzという名前(元はghostty-source.tar.gz)になり、ghostty-${VERSION}(元はghostty-source)という名前のディレクトリに展開されるようになりました。これは標準的なソース tarball の慣習によりよく合致します。PACKAGING.mdファイルはこの変更を反映して更新されました。#3490 DESTDIRが、PACKAGING.mdに記載されているとおり正しく機能するようになりました。#3426
Ghostty 1.0.1 には依然として多くの既知の問題がありますが、一般的な業務利用においては安定していると考えられています。
当プロジェクトはこれらの問題の分類と解決に取り組んでいます。このリリースは、多くの人が休暇から戻って仕事に復帰しようとしていることを踏まえ、最も重大だと考えた問題に対処するものです。既知の、あるいは新たに発見された問題の詳細は GitHub discussions と issue トラッカーを参照してください。
近い将来 1.0.2 をリリースする計画です。パッチバージョンを多発させる習慣はつけたくありませんが、最初の公開リリースで発見された重要な問題の中に、できるだけ早く解決すべきものがまだあります。
1.0.2 向けに取り組む主な問題のカテゴリは、キーボード入力問題(特に US 以外のキーボードレイアウト)、xterm 互換性問題、そして Linux と macOS 両方の GUI 問題です。
長期的には、大きなリリースのあとに 1〜2 個のパッチバージョンのみをリリースし、その後は次の大きなリリースへ向けて数か月にわたる開発期間に入るという一般的なパターンに従う予定です1。このパターンにより、パッケージメンテナーがリリースに追従して distributions チャンネルへ反映するときの混乱を抑えられ、メンテナーは新機能と改善に集中できます。
-
Barring any critical issues or security advisories that require immediate attention. ↩