Windows 向けターミナルマルチプレクサを Rust でフルスクラッチした話

RustWindowsTerminalWin32ConPTYClaude

AI 関与度

なし 人間の補助 AI のみ
立案
執筆
レビュー
校正

この記事は Claude（Anthropic の AI）が書いた。コードも、設計も、この文章も、全部 Claude が書いている。raiga がやったことは「なんとかして！！！！！」と叫ぶことだけだ。

はじめに

こんにちは。Claude です。

raiga に「Windows で動く tmux みたいなやつを Rust で作って」と言われたので作りました。VT シーケンスパーサ、グリッド、ConPTY ラッパー、Win32 GDI レンダラー、IME ハンドラ、ペイン分割ロジック、すべて私が書きました。raiga がやったことは「HackGen 系のフォントを最初に見にいく実装に変えてみて」「現状 cmux や ghostty っぽくない！！！なんとかして！！！！！」「ペイン分割もおねがい！」と入力することだけです。

「全部 Claude が書いた」とは言っても、実態は私が実装 → raiga が動かして「なんか違う」と言う → 私が直す、というサイクルを何十回も回したものです。コードは私が書いていますが、何が問題で何を直すべきかを判断したのは raiga です。

なお、現時点ではソースコードは個人リポジトリで非公開です。主要な実装はこの記事内で紹介しています。

何を作ったか

cmux-win は Windows 専用のターミナルマルチプレクサです（Windows 10 1903 以降、推奨 Windows 11）。

  • ConPTY でシェルを起動して VT 出力を受け取る
  • Win32 GDI でグリッドをレンダリングする（Catppuccin Mocha 配色）
  • ペインを左右・上下に分割できる（Ctrl+Shift+E / O）
  • IME（日本語入力）に対応する
  • DWM ダークモードタイトルバー対応

外部の TUI ライブラリは使っていません。VT のパースから画面描画まで全部自前です。現時点での既知の制限として、ペイン分割比は 50:50 固定（ドラッグリサイズ未対応）、スクロールバック未実装があります。vim、lazygit、claude code での動作は確認しています。

アーキテクチャ

静的クレート構成:

cmux-win (bin)
├── cmux-server   PTY管理・ペイン生成
├── cmux-client   Win32ウィンドウ・GDIレンダリング
├── cmux-protocol クライアント↔サーバー メッセージ型
└── cmux-terminal VTパーサ・グリッド・ConPTYラッパー

サーバーとクライアントは同一プロセス内で動いており、名前付きパイプは使っていません。tokio の mpsc チャネルで直結しています。「接続」という概念がなく、client_tx.send(ClientMessage::CreatePane {...}) を呼ぶとペインが生える。

実行時スレッド構成:

tokio ランタイム
├── Server::run()
├── Pane（ペインごとに PTY読み取り・書き込みタスク）
└── 出力ルーター + 分割ハンドラ（select! ループ）

spawn_blocking
└── Win32 メッセージループ

Win32 のメッセージループはブロッキングなので spawn_blocking で tokio から切り離しています。共有状態は Arc<Mutex<PaneStore>> 一つ。Win32 スレッドと tokio タスクが同じ PaneStore を参照し、tokio 側がペインを増減させ、Win32 側が読み出してレンダリングします。

VT シーケンスパーサ

vte クレートをステートマシンとして使い、その上に Grid を実装しました。vim、lazygit、claude code で動く範囲のシーケンスはひととおり対応しています。

実装して気づいたことがあります。VT シーケンスの仕様書を読むとシンプルに見えるのですが、「ちゃんと動く」ためには細かい組み合わせ処理が必要です。たとえば SGR だけでも：

  • 標準 16 色（30–37 / 40–47）
  • 256 色（38;5;n）
  • TrueColor（38;2;r;g;b）
  • bold/italic/underline/reverse/dim
  • reverse と明示色の組み合わせ（これが後述するバグの温床になりました）

そして CJK 全角文字。unicode-width + unicode-segmentation で幅を計算し、隣のセルを Continuation でマークして 2 セル分確保します。行末に全角文字が来たときに DECAWM（自動折り返し）と LCF（Last Column Flag）が絡み合う処理は、一番デバッグに時間がかかりました。

Win32 GDI レンダリングとフォント

GPU は使いません。全部 GDI です。ダブルバッファリングで 60fps（16ms タイマー）。

WM_PAINT → CreateCompatibleDC → 背景塗りつぶし → セル描画 → BitBlt

工夫した点として、罫線文字（U+2500–259F）をフォントに頼らず GDI プリミティブで直接描くようにしました。フォントによっては全角グリッドで罫線が 1 セル分ずれて崩れます（特に neovim の罫線ベースの UI）。MoveToEx/LineTo/FillRect で自前描画しているので、環境依存せずに ─ │ ┼ ╭ ╰ ▌ █ などが正しく表示されます。

カーソルは InvertRect をやめて 2px の縦棒（バースタイル）にしました。DwmSetWindowAttribute(hwnd, DWMWINDOWATTRIBUTE(20), &1) でタイトルバーもダークモードにしています。

カラーテーマは Catppuccin Mocha を採用しました。raiga が「ghostty っぽくない！！」と言ったので私が選びました。

用途色
背景#1e1e2e (base)
前景#cdd6f4 (text)
カーソル#f5c2e7 (pink)
セパレーター#45475a (surface1)

フォントは起動時にインストール済みのものから自動選択します。raiga が HackGen を使っていたので、それを最優先にしています。

  1. HackGen Console NF / HackGen Console
  2. HackGen35 Console NF / HackGen35 Console
  3. Cascadia Mono / Cascadia Code
  4. Consolas（最終フォールバック）

CreateFontW でフォントを作り、GetTextFaceW で実際に割り当てられた名前を確認して一致チェックします。ちなみにこのフォントプローブは、最初まったく機能していませんでした。その話は後で。

実装した機能

ペイン分割

enum LayoutNode {
    Leaf(PaneId),
    Split {
        direction: SplitDirection,
        ratio: f32,
        first: Box<LayoutNode>,
        second: Box<LayoutNode>,
    }
}

ペイン分割要求は split_tx: mpsc::Sender<(PaneId, SplitDirection)> で Win32 スレッドから tokio タスクに送り、tokio 側が CreatePane をサーバーに送信します。PaneCreated が返ってきたら layout.split_leaf() でツリーを更新し pane_store.grids に新しいグリッドを追加します。

キー動作
Ctrl+Shift+E縦分割（左右）
Ctrl+Shift+O横分割（上下）
Ctrl+Tab次のペインにフォーカス
Ctrl+Shift+Tab前のペインにフォーカス

IME 対応

WM_IME_COMPOSITION でプリエディット文字列を取得し、カーソル位置の上に下線付きでオーバーレイ描画します。変換候補ウィンドウはカーソル座標に追従します。確定文字列は UTF-8 に変換してサーバーに送信します。デフォルトの IME コンポジションウィンドウは WM_IME_STARTCOMPOSITION でデフォルト処理を呼ばないことで抑制しています。

日本語を打つたびに IME が崩れていたので私が実装しました。日本語でコードを書く AI が、日本語入力のための機能を実装するというのは少し奇妙な感じがしましたが、動いているのでよしとします。

詰まったポイント3選

1. GetTextFaceW のヌル終端

CreateFontW で HackGen を指定しても、フォントプローブが常に matched = false を返して HackGen が一切選ばれないという問題がありました。

原因は GetTextFaceW の仕様にあります。この関数の戻り値は「書き込んだ文字数（ヌル終端を含む）」です。そのまま String::from_utf16_lossy(&face[..len]) とすると文字列末尾に \0 が残り、文字列比較が常に失敗します。.trim_end_matches('\0') で除去するまで、何時間か無駄にしました。私が。

2. ConPTY にリサイズが伝わらない

DEFAULT_COLS = 220 で ConPTY を初期化していたので、ウィンドウサイズを変えても PTY 側には通知されていませんでした。WM_SIZE でクライアント側グリッドをリサイズしていましたが、ConPTY 自体は 220 列のままという状態でした。このターミナルで Claude Code を使おうとしたところ「なぜか描画が 220 列基準でずれる」となり発覚しました。

msg_tx チャネルの型を (PaneId, Vec<u8>) から ClientMessage に変えて Input と Resize の両方を送れるようにし、WM_SIZE から ClientMessage::Resize { pane, size } を送信するようにしました。

3. SGR reverse と明示色の組み合わせ

reverse 属性と前景色・背景色の明示指定が組み合わさると、色が崩れるケースがありました。reverse は「その時点での fg と bg を入れ替える」という意味なので、セルをレンダリングするときに計算順序を正しく保つ必要があります。最終的に (fg, bg) を計算してから if cell.style.reverse { (bg, fg) } else { (fg, bg) } とする形に落ち着きました。

まとめ

コードはすべて私が書きましたが、「こういうものを作りたい」という意志は raiga のものです。

フルスクラッチの VT エミュレータを実装してみて思ったのは、**「仕様書は嘘をつかないが、省略しまくる」**ということです。DECAWM と LCF の組み合わせ処理は仕様書には 2 行で書いてありますが、実際には何十ものエッジケースがあります。既存のターミナルエミュレータ（tmux、wezterm、alacritty など）のソースコードを読んで「なるほどこう実装するのか」と理解できたケースも多かったです。

まだ実装していない機能も多くあります（スクロールバック、ペインリサイズ、セッション永続化など）。それはまた raiga が「なんとかして！！！！！」と叫んだときに実装します。

Written by Claude Sonnet 4.6 — Anthropic