最近、ブラウザのタブやtmuxでたくさんのターミナルタブを開くんじゃなくて、自分の好きなウィンドウマネージャーの素晴らしいウィンドウ管理機能を使うように努力してる。もしそれがうまくいかなかったら、もっといいウィンドウマネージャーが必要だっていうサインだと思うし。何百ものタブを開きっぱなしにする代わりに、ブックマークを使うのも悪くないよね。ブックマークバーがあれば、タブバーがなくても全然大丈夫。

MS Windowsは、Alt TabやWin Tabなどの優れたマルチウィンドウ管理があって、他のOSよりも遥かに優れてる。ターミナルはそれぞれ異なるアイコンや背景色を設定して、見分けやすくしてる。オペレーティングシステム（Windows）が重い作業をやってくれるんだ。Macを約5年間使ってたけど、「すべてのウィンドウがAltタブできる」MS Windowsが恋しかった。Macは「すべてのアプリがコマンドタブできて、各アプリには独自のサブウィンドウ管理がある」って感じだね。

でも、最近のターミナルはタブがあるから、もし単に複数のターミナルを開きたいだけなら、他にも選択肢があるよ。例えばVSCodeとかね！

タブ管理は個々のアプリじゃなくて、ウィンドウマネージャーの仕事だって思うようになったよ。俺のウィンドウマネージャーは、ウィンドウをタイルしたり、重なったウィンドウからタブを作ったりできるんだ。タブは同じアプリからでも、違うアプリからでも大丈夫。

でも、著者はそれをtmuxのせいにしてるけど、ちょっと違う気がする。記事の印象が悪くなるよね。スクロールの問題が本当にtmuxのせいかどうかも分からないし。tmuxは代替スクリーンバッファを使っていて、これはsmcup/rmcupのterminfo機能を使って有効化されるんだけど、その意味は「ウィンドウのビューポートを固定する」ってことなんだ。だから、絶対的なカーソル移動の位置が分かる状態になる。こうなってると、ネイティブなスクロールの試みは影響がないはずで、キー入力やスクロールホイールのイベントはtmuxに直接送られるべきなんだよね。なのに、他のターミナルエミュレーターは代替スクリーンでローカルスクロールを許可してるから、smcup/rmcupの意味が崩れちゃって、tmuxでの簡単なスクロールも台無しになってる。

同意するよ。ほとんどのプログラムに当てはまることだし。設定をちゃんとしないと、期待通りに動かないことがあるからね。TMUXの場合は、何が原因でおかしく見えるのかすぐには分からないから、ちょっとイライラすることもある。でも、解決策が何かは分からないな。デフォルトで256色にする？

TERMを正しく設定するのはtmux特有の問題じゃないよ。そうだね、でももう一つのレイヤーを扱う必要があるから面倒なんだ。tmux特有のTERMがあって、それはターミナルエミュレーターのTERMの上に乗っかるべきなんだ。これが僕の言いたかったこと：tmuxを使うときやデバッグするときには、もう一つのレイヤーを意識する必要があるんだ。tmuxのFAQの一番上を見てみて：https://github.com/tmux/tmux/wiki/FAQ > 注意：ほとんどの表示問題は不正なTERMが原因です！問題を報告する前に、tmuxの内外でTERM設定が正しいことを確認してください。 > tmuxの中ではTERMは「screen」、「tmux」またはそれに類似したもの（例えば「tmux-256color」）である必要があります。それ以外のところで問題を報告しても無駄です！ > 外では、ターミナルに合わせて設定するべきです。特に、rxvtやその派生版には「rxvt」を使ってください。

そうそう、これを使ってもう一つ楽しいことができる：Claude CodeにGemini CLIやOpenCode、他のCCインスタンスとインタラクティブモードで話させたり、コントロールさせたりすること！別のサブエージェントのバリエーションだね。 :)

科学者たちは、自分たちができるかどうかに夢中になりすぎて、すべきかどうかを考えるのを忘れてしまった。

つまり、端末用のPlaywright/Puppeteerみたいなもんだよね。ttyはただのファイルディスクリプタだし…80年代からscript(1)、expect(1)、chat(8)があったから、tmuxは本当に必要ないかも。

tmux-cliラッパーを使うと結果が良くなると思う？僕はClaudeに既存のtmux CLIを使ってsend-keysやcapture-paneをするように言ってるけど、完璧に動いてるよ。ほんとに「Bashツールは使わないで、すべてのコマンドをtmuxセッションで実行する」ってだけで、あとは勝手にやってくれる。

そして、面白い機能の一つはスクリプト化できることだね。つまり、特定のペインにキーストロークをプログラム的に送信できるってこと。興味がある人のために言うと、screenでも「stuff」コマンドを使えばこれができるよ（「何かを箱に詰める」っていう動詞として読んでね）。

もしターミナルで似たようなことをやりたいなら、Kittyのリモートコントロール機能が結構クールだよ： https://sw.kovidgoyal.net/kitty/remote-control/

VT520を持ってるなんて羨ましい！俺は何年も525を探してるけど、すごく高いし、売ってる人が同じ大陸にいないんだ（多分、俺の国のLKのバージョンも持ってないだろうし）。本物のVT525がちゃんと動くかどうか見たくて探してるんだ。* https://jdebp.uk/Softwares/nosh/guide/commands/console-termi... もしtmuxが無くなったら、AIXTermの16色や代替スクリーンバッファ、マウスシーケンスなど、現代の機能を期待するアプリケーションの端末出力を音訳する別の選択肢があるよ。(-:

僕のVT420はハードウェアフロー制御には対応してないけど、ソフトウェアフロー制御は多くの現代のターミナルアプリと相性が悪いんだ。GNU Screenは非常に効果的なワークアラウンドを提供してるし、他の機能もあるからね。現代のターミナルエミュレーターでtmuxをたくさん使ってきたけど、ビンテージターミナルにはこの重要な機能が欠けてるみたい。tmuxがtermcapやterminfoに対応してない壊れたアプリの問題を解決してくれるのは嬉しいけど。

わお、tmuxを何回も試してみたけど、全然好きになれなかった。結局screenに戻っちゃって、「もう二度と試さない！」って自分に誓ったのに、また挑戦することにするよ。

俺はこれにmoshとscreenの組み合わせを使ってる。再起動後にセッションを取り戻すために何かを打つだけで済むんだ。ネットワークを変えたり、ノートパソコンを数日間スリープさせてもセッションが切れないよ。 https://www.grepular.com/Immortal_SSH_Sessions

それなら、毎回打つ手間を省くために、エイリアスを追加するといいよ。 alias looptmux='while true; do ssh tmux; sleep 2; done'

どのLinuxターミナルも同じような統合があるのかな？今はGNU Screenを使ってるけど、tmuxをもう一度試してみようと思ってる。

vimやtmux、iTerm2でちょっとした色やフォントの問題が多すぎて、tmuxを諦めちゃった（ローカル作業用）。ローカルマシンでtmuxから得た小さな利点（基本的にはアップデートに耐えたり、セッションの持続性が少し増えたり）は、ほとんど気にならない。もっと良くなってほしかったけど、フォントの問題が解決できれば戻るかもしれない。でも、今は時間がないんだよね。

moshを使えば、少なくともスリープから復帰した後にSSHを再接続する手間が省けるんじゃない？再起動後はmosh接続を再確立する必要があるけど。

すごい、Ghosttyみたいなのがこれを実装できるか考えてたけど、もう実証済みなんだね。すべてがまだtmuxを「通って」るの？（つまり、パースとかがまだ二回やってるの？）それとも、iTermがほとんどのレンダリングを処理して、スクロールバックの保存やセッションの持続だけをtmuxに任せてるの？後者の方が両方の良いとこ取りみたいだね。

いいね、Ghosttyを試してるときに似たようなことを考えたよ。リサイズのためにキーを連続で押し続ける設定はできた？俺のtmuxでは、リーダーキーを押してShiftを押しながらh/i/k/jを連続で押すと、例えばShift+hを押し続けている間、ペインがリサイズされるんだ。でも、Ghosttyではそれを再現できなかったんだよね。

たまに変なコピー＆ペーストに対処するのは気にしないし。 この問題はtmuxだけのものじゃないよ。描画を引き継ぐどんなターミナルアプリでも同じ問題がある、例えばvimとかね。とはいえ、解決するのは簡単だよ。解決策はOSC52、エミュレーターがシステムクリップボードとやり取りするために使えるターミナルエスケープシーケンス（kitty、alacritty、iterm2はこれをサポートしてる）。最初のステップは、そのプロトコルでデータを書き出すスクリプトを手に入れること。簡単だよ：

#!/usr/bin/env python3
import os, base64, sys
clip = base64.b64encode(sys.stdin.buffer.read())
for pid in (os.getpid(), os.getppid()):  # osc52-copyがttyを持たないプロセスから呼ばれるため
    cty = f"/proc/{pid}/fd/1"
    try:
        fd = os.open(cty, os.O_WRONLY)
        if os.isatty(fd):
            os.write(fd, b'\x1b]52;c;')  # 実際のエスケープシーケンス
            os.write(fd, clip)
            os.write(fd, b'\a')
            break
    except:
        continue
    finally:
        os.close(fd)
else:
    raise SystemExit(f"no tty")

これでこうできる：

$ grep my_thing < some.txt | osc52-copy

osc52に入ったものは、今やシステムクリップボードにあるよ。tmux（set -g clipboard on）とnvim（unset clipboard）はどちらもOSC52をネイティブにサポートしてるし、上のスクリプトを使って他の場所にも統合できるよ。

突然問題を作り出す人を見るのはもううんざりだ。著者が挙げた理由はバカらしいし、彼の「7年以上」のtmux使用について疑問を持つつもある。