CommandCodeAI / CommandCodeAI/command-code
Renderer rows silently corrupt Kitty APC graphics escapes — blocks inline images from mods
まだ誰も着手していません。
- 主要言語
- 言語のデータがありません
- スター
- 4k
- フォーク
- 350
- PR マージ指標
- 30日以内にマージされた PR はありません
説明
Summary
Mod renderer rows silently corrupt Kitty Graphics Protocol (APC) escape sequences, making inline images impossible from mods even though the docs promise row styling with raw codes (api.md: "style them with ansi escapes — picocolors, @commandcode/tui helpers, or raw codes"). SGR escapes survive; multi-line APC payloads do not. This bug blocks any cmd.ui.image()-style feature (see #633 §7) and any mod that talks to a terminal graphics protocol.
Repro (mod-side, minimal)
A mod registers a renderer whose first row is a complete kitty APC (\x1b_Gf=100,q=1,a=T,...;<base64>\x1b\\). The same bytes written directly to fd 1 draw the image; the same bytes returned as a renderer row never draw. Verified today on kitty 0.42 with a browser-rendered PNG (784×62), all in a live session:
| Delivery | Result |
|---|---|
writeSync(1, apc) from inside the renderer |
image draws |
| APC as first renderer row, 4096-byte payload | no image (row wraps at terminal width → sequence corrupted) |
APC split into 96-byte / 64-byte row chunks, chained with m=1/m=0 |
still no image |
Root cause (two layers)
- Wrap corruption: a KB-scale APC cannot fit one terminal line; the feed wraps long rows at the column width, splitting the sequence mid-payload. Kitty silently drops malformed graphics sequences when
q=1— no error reaches the mod or the user. - Chunk-chain interleaving: splitting into line-sized chunks per the protocol's own
m=continuation mechanism doesn't help either — the feed joins rows with\nand full-screen repaints can split the chain across writes, and interleaved bytes between continuation chunks invalidate the transmission (again silently).
The SGR-red-caption probe proved the pipe itself passes escapes — the chain specifically dies between chunks.
What would fix it
Either of:
- APC passthrough in the row pipeline — treat
\x1b_G…\x1b\\as an atomic zero-width unit in the width calculator and row sanitizer (the same allowance SGR already gets), so a chain of line-sized APCs rides the row stream intact. Mod-side we already chunk to 64-byte rows precisely for this. - A first-class image API — e.g.
cmd.ui.image({ path, rows })that owns protocol detection, chunking, placement, and repaint behavior (would supersede/fold into #633 §7cmd.ui.image(); this issue supplies the pipeline groundwork it needs).
Until then, mods must fall back to writing directly to fd 1, which draws the image but anchors it to whatever the cursor happens to be at render time — placement drifts relative to the feed block (phantom padding), and it breaks under scroll.
Environment
- Command Code 1.37.0 (npm global)
- kitty 0.42,
TERM=xterm-kitty, interactive TTY (graphics protocol verified working via raw fd write) - Repro mod:
kitty-graph-repro.ts(attached to this issue) — encoder, capability gate, and both delivery strategies; the Delivery A/B switch is a one-line change in the renderer
Related
- #633 §7 —
cmd.ui.image()feature request (the umbrella this bug blocks) - #609 — adjacent: feed rendering surface limitations for mods
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
添付された kitty-graph-repro.ts から始め、width calculator と row sanitizer を含む renderer の行パイプラインを調査します。fd への直接書き込みと行として返される APC を比較し、続いて指定された kitty 環境で、完全な APC シーケンスとチャンク化された APC シーケンスが、破損やインターリービングなしに再描画を通過することを検証します。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- typescript
- 領域
- cli
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 活発
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 45/100