ありがとう。Windowsはサポートしてるよ。Windows TerminalとPowershellでテストしたからね。リリースプランからその問題を削除したのは、まだ全てのサブタスクが終わってないからなんだ。それに、Windowsユーザーからのフィードバックがあまりなかったのも理由かな。例えば、WindowsのVMでGPUパススルーをうまく動かせなかったから、シェーダーのテストもまだできてないんだ。

どういう意味？実は、SixelやKittyの画像プロトコルみたいなターミナル画像プロトコルはあんまり好きじゃないんだ。テキストだけを使う制約を大事にしてるから。リアルなグラフィックスに踏み込むと、ターミナルの魂が失われる気がするんだよね。

そうだね、どのGUIターミナルも自分のスクロールバックバッファを管理してるよ。Tattooやtmuxがそれぞれバッファを持ってるのは、彼らが基本的にターミナルエミュレーターだからなんだ。例えば、ターミナルエミュレーターが10個のtmuxペインを持ってたら、それぞれの履歴を見れるのは当然だよね。Tattooは自分のスクロールバックを管理してるけど、これは他のプロセスにプログラム的にスクロールバックを提供する唯一の方法なんだ。例えばミニマップとかね。面白いことに、Alacrittyは最初はスクロールバックをネイティブでサポートしてなかったんだ。tmuxみたいなマルチプレクサにその問題を任せたかったから。だから、ターミナルエミュレーターがスクロールバックをサポートしなくてもいい前例があるんだ。Tattooではtmuxがちゃんと動くはずだけど、気をつけてほしいのは、Tattooが入力を処理するから、スクロールとかのイベントがtmuxに届かないことがあるかもしれないってこと。その場合、Tattooが認識しないカスタムtmuxキー割り当てを作ることができるよ。それと、Tattooはtmuxがホストを制御する「オルタネートスクリーン」状態を認識することも覚えておいてね。そういう場合、Tattooはマウスのスクロールホイールみたいなスクロールイベントを基盤プロセスに転送するんだ。明るいテーマの例はまだないけど、基本的にはちゃんと動くはずだよ。

ターミナルのスクリーンショットを撮って、それを解析して本当の色のサポートを判断するってアイデアは確かに新しい、 これをもっと良くする方法は、OSC 1 0 ; ? ST（前景色を問い合わせ）、OSC 1 1 ; ? ST（背景色）、次にOSC 4 ; {n} ; ? STを送ることだよ。ここで{n}はn番目のXTermカラー。詳しくはここを見てね：https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h4-O...

試してくれてありがとう。どうやらあなたのターミナルかスクリーンショッターが純粋な赤のマーカー列を忠実に描写してないみたいだね（これはパーサーのキャリブレーションに必要なんだ）。赤は#ff0000であるべきだけど、スクリーンショットは#ea3323を使ってる。進捗を追うためにGithubにイシューを作ったよ：https://github.com/tattoy-org/tattoy/issues/98 もっと詳細を追加してくれたらすごく助かるよ、きっとあなたみたいな人が他にもいるはずだから。

すごい、いろいろ教えてくれてありがとう。前景と背景のピクセルの比率がテキストの可読性に影響を与えるなんて考えたこともなかったよ。もちろん、考えてみればそれは完全に理にかなってるね。これがWCAG基準のどこかで考慮されたことがあるか知ってる？パレットのスクリーンショットとOSC 4の両方をサポートしようと思ってるんだけど、LC_*変数は前に見たことがあるけど、今のシェルにはないみたい。これらがパレットインデックスの真の色の値の別のソースになり得るってこと？

XTerm OSC 4はカラーパレットを調べる能力が非常に限られているかもしれない。少なくともstではデフォルトの前景、背景、カーソルの色しか見えないし、フル16色パレットは見えないんだ。これは主に@hnlmorgによる他のスレッドのポイントを強調するだけだね。 どのstのバージョン？私の場合、0.9.2ではseq 0 255のnに対して色立方体全体を印刷するよ；do printf '\033]4;%d;?\033\\' "$n"; done; read（驚くことに、微妙に壊れてるけどね：STを送ったけど、応答がBELで終わっちゃう...）