CommandCodeAI / CommandCodeAI/command-code

Renderer rows silently corrupt Kitty APC graphics escapes — blocks inline images from mods

オープン
#763 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

主要言語
言語のデータがありません
スター
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)
  1. 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.
  2. 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 \n and 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:

  1. 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.
  2. 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 §7 cmd.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

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. 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

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。