[v0.1/Protocol Review] Freeze the terminal-protocol not-yet trio (DECCARA/DECRARA, ?2048, XTSMGRAPHICS) #181

New issue

Closed

opened 2026-09-07 15:53:47 +09:00 by natsukium · 1 comment

natsukium commented

2026-09-07 15:53:47 +09:00

Owner

Background

docs/reference/protocols/support-matrix.md marks three sequences as ❌ not yet, but none of them has a stance in docs/explanation/protocols/landscape.md and none is tracked by any issue (searched DECCARA, 2048/in-band, XTSMGRAPHICS across all issues: zero hits). Before the publish freeze — when breaking changes are still free — each needs a decision: implement now, defer with a tracking issue, or record as a non-goal.

The three items

1. DECCARA / DECRARA (change / reverse attrs in area)

Status: support-matrix.md:63 — ❌ not yet.
Neighbors are done: DECCRA / DECFRA / DECERA / DECSERA are ✅, DECRQCRA checksum is ✅, and the shared Pt;Pl;Pb;Pr bounds model is specified in docs/reference/protocols/vt-compliance.md "Rectangular editing" (vt-compliance.md:56-74).
The rectangle bounds model, selective-erase attribute handling (DECSERA ✅), and the SGR pen already exist, so CARA/RARA look like a small increment on a finished family — unless there is a reason they were skipped (attribute-merge semantics?).

2. In-band resize notify (`?2048`)

Status: support-matrix.md:75 — ❌ not yet.
Sibling notify mode ?2031 color-scheme (+ DSR ?996/?997) is ✅ (OS light/dark → PTY), so the notify plumbing pattern exists.
Question: is ?2048 the next notify mode felis wants, or does window-size reporting stay out (CSI 14/15/16 t stubbed 0;0, XTWINOPS 🚫) and ?2048 with it? The answer should be recorded in landscape.md either way — currently neither adopt nor reject is written.

3. XTSMGRAPHICS (graphics geometry `CSI ? … S`)

Status: support-matrix.md:148 — ❌ not yet.
Kitty graphics itself (t/d/p/q/a, animation, z=, Unicode placeholder) is fully ✅. A graphics query gap beside a complete graphics implementation is the kind of asymmetry a consumer (yazi, presenterm) will trip over: the producer can place images but cannot query geometry.
Question: implement the query for the implemented subset, or record why geometry queries stay out while placement is in.

Proposal

For each of the three, record adopt / defer / reject in docs/explanation/protocols/landscape.md (the skill-mandated first stop: add-escape-sequence §1) and flip or keep the support-matrix.md status accordingly.
Adopt → file the implementation issue with snapshot tests (snapshot_csi*.rs / snapshot_osc.rs) and, where applicable, an esctest movement.
Defer → keep ❌ not yet with the tracking issue number beside it (the matrix already links open work to issues in prose; make it per-row).
Reject → flip to 🚫 with the non-goals.md rationale, same as Sixel / XTWINOPS.
DECCOLM's resize arm is already a recorded conscious omission (landscape.md:65); use it as the template for how a "parsed but not honored" verdict is written.

Acceptance criteria

No ❌ not yet row in support-matrix.md is without either a tracking issue or a landscape-stance line.
landscape.md carries an explicit line for rectangular-attribute ops, ?2048, and XTSMGRAPHICS (adopt/reject/defer + why).
Any adopted item has an implementation issue; any rejected item has a non-goals.md entry.

Sources reviewed

docs/reference/protocols/support-matrix.md (rows cited above)
docs/explanation/protocols/landscape.md (§CSI, §Modern protocols; no stance lines found for the three)
docs/reference/protocols/vt-compliance.md "Rectangular editing", "Reporting and queries"
Issue search: DECCARA, resize notify, XTSMGRAPHICS, in-band — no tracking issue exists

## Background `docs/reference/protocols/support-matrix.md` marks three sequences as `❌ not yet`, but none of them has a stance in `docs/explanation/protocols/landscape.md` and none is tracked by any issue (searched `DECCARA`, `2048`/`in-band`, `XTSMGRAPHICS` across all issues: zero hits). Before the publish freeze — when breaking changes are still free — each needs a decision: implement now, defer with a tracking issue, or record as a non-goal. ## The three items ### 1. DECCARA / DECRARA (change / reverse attrs in area) - Status: `support-matrix.md:63` — `❌ not yet`. - Neighbors are done: DECCRA / DECFRA / DECERA / DECSERA are `✅`, DECRQCRA checksum is `✅`, and the shared `Pt;Pl;Pb;Pr` bounds model is specified in `docs/reference/protocols/vt-compliance.md` "Rectangular editing" (`vt-compliance.md:56-74`). - The rectangle bounds model, selective-erase attribute handling (DECSERA `✅`), and the SGR pen already exist, so CARA/RARA look like a small increment on a finished family — unless there is a reason they were skipped (attribute-merge semantics?). ### 2. In-band resize notify (`?2048`) - Status: `support-matrix.md:75` — `❌ not yet`. - Sibling notify mode `?2031` color-scheme (+ `DSR ?996`/`?997`) is `✅ (OS light/dark → PTY)`, so the notify plumbing pattern exists. - Question: is `?2048` the next notify mode felis wants, or does window-size reporting stay out (`CSI 14/15/16 t` stubbed `0;0`, XTWINOPS `🚫`) and `?2048` with it? The answer should be recorded in `landscape.md` either way — currently neither adopt nor reject is written. ### 3. XTSMGRAPHICS (graphics geometry `CSI ? … S`) - Status: `support-matrix.md:148` — `❌ not yet`. - Kitty graphics itself (`t/d/p/q/a`, animation, `z=`, Unicode placeholder) is fully `✅`. A graphics query gap beside a complete graphics implementation is the kind of asymmetry a consumer (yazi, presenterm) will trip over: the producer can place images but cannot query geometry. - Question: implement the query for the implemented subset, or record why geometry queries stay out while placement is in. ## Proposal - For each of the three, record adopt / defer / reject in `docs/explanation/protocols/landscape.md` (the skill-mandated first stop: `add-escape-sequence` §1) and flip or keep the `support-matrix.md` status accordingly. - Adopt → file the implementation issue with snapshot tests (`snapshot_csi*.rs` / `snapshot_osc.rs`) and, where applicable, an esctest movement. - Defer → keep `❌ not yet` with the tracking issue number beside it (the matrix already links open work to issues in prose; make it per-row). - Reject → flip to `🚫` with the `non-goals.md` rationale, same as Sixel / XTWINOPS. - DECCOLM's resize arm is already a recorded conscious omission (`landscape.md:65`); use it as the template for how a "parsed but not honored" verdict is written. ## Acceptance criteria - [ ] No `❌ not yet` row in `support-matrix.md` is without either a tracking issue or a landscape-stance line. - [ ] `landscape.md` carries an explicit line for rectangular-attribute ops, `?2048`, and XTSMGRAPHICS (adopt/reject/defer + why). - [ ] Any adopted item has an implementation issue; any rejected item has a `non-goals.md` entry. ## Sources reviewed - `docs/reference/protocols/support-matrix.md` (rows cited above) - `docs/explanation/protocols/landscape.md` (§CSI, §Modern protocols; no stance lines found for the three) - `docs/reference/protocols/vt-compliance.md` "Rectangular editing", "Reporting and queries" - Issue search: `DECCARA`, `resize notify`, `XTSMGRAPHICS`, `in-band` — no tracking issue exists

natsukium added the

release/v0.1.0

priority/P1

labels

2026-09-07 15:53:51 +09:00

natsukium commented

2026-09-07 16:31:32 +09:00

Author

Owner

Triage plan (2026-09-07)

Decisions (user, 2026-09-07):

DECCARA / DECRARA: adopt. The rectangular family (DECCRA/DECFRA/DECERA/DECSERA, DECRQCRA) is complete and the Pt;Pl;Pb;Pr bounds model is specified; change/reverse attributes in area is a small increment on it. Implementation is its own issue (filed alongside this plan); the matrix row stays ❌ not yet (#<impl issue>) until it lands.
?2048 in-band resize notify: adopt. kitty implements it, the notify-mode plumbing exists for ?2031, and felis's daemon-owned geometry (window resize, sessions retarget, remote clients) is exactly the case in-band notification serves better than SIGWINCH alone. Window-size reporting (CSI 14/15/16 t stubs, XTWINOPS 🚫) stays out; the landscape line must say why the two differ (a notification the terminal pushes vs a query the application pulls that leaks host geometry). Implementation is its own issue; row stays ❌ not yet (#<impl issue>).
XTSMGRAPHICS: reject. It is xterm's Sixel/ReGIS geometry query; kitty does not implement it and the Kitty graphics protocol has its own query path (a=q), which felis implements. Same reasoning as the Sixel non-goal. Flip the row to 🚫 with a non-goals.md entry.

Approach

Docs-only PR for this issue:

docs/explanation/protocols/landscape.md: one stance line each (adopt / adopt / reject, with the why above and a "Revisit if …" trigger for the reject), written in the DECCOLM style the issue points at.
docs/reference/protocols/support-matrix.md: DECCARA/DECRARA and ?2048 rows gain the tracking issue number; XTSMGRAPHICS row becomes 🚫.
docs/explanation/non-goals.md: XTSMGRAPHICS entry beside Sixel.
File the two implementation issues before opening the PR so the matrix can cite their numbers (title style [v0.1/Protocol] Implement …, body: what, where in the parser/grid/daemon path, snapshot tests to add, esctest movement if any; end with "Split from #181.").

Tests

None beyond just prose-check and the docs-tree guards; the doc-cascade grep sweep for DECCARA, 2048, XTSMGRAPHICS across docs/.

Cascade

CHANGELOG.md is not touched (no behavior change yet). docs/reference/spec.md only if a REQ cites the matrix rows.

## Triage plan (2026-09-07) **Decisions (user, 2026-09-07):** 1. **DECCARA / DECRARA: adopt.** The rectangular family (DECCRA/DECFRA/DECERA/DECSERA, DECRQCRA) is complete and the `Pt;Pl;Pb;Pr` bounds model is specified; change/reverse attributes in area is a small increment on it. Implementation is its own issue (filed alongside this plan); the matrix row stays `❌ not yet (#<impl issue>)` until it lands. 2. **`?2048` in-band resize notify: adopt.** kitty implements it, the notify-mode plumbing exists for `?2031`, and felis's daemon-owned geometry (window resize, `sessions retarget`, remote clients) is exactly the case in-band notification serves better than SIGWINCH alone. Window-size *reporting* (`CSI 14/15/16 t` stubs, XTWINOPS 🚫) stays out; the landscape line must say why the two differ (a notification the terminal pushes vs a query the application pulls that leaks host geometry). Implementation is its own issue; row stays `❌ not yet (#<impl issue>)`. 3. **XTSMGRAPHICS: reject.** It is xterm's Sixel/ReGIS geometry query; kitty does not implement it and the Kitty graphics protocol has its own query path (`a=q`), which felis implements. Same reasoning as the Sixel non-goal. Flip the row to `🚫` with a `non-goals.md` entry. ## Approach Docs-only PR for this issue: - `docs/explanation/protocols/landscape.md`: one stance line each (adopt / adopt / reject, with the why above and a "Revisit if …" trigger for the reject), written in the DECCOLM style the issue points at. - `docs/reference/protocols/support-matrix.md`: DECCARA/DECRARA and `?2048` rows gain the tracking issue number; XTSMGRAPHICS row becomes `🚫`. - `docs/explanation/non-goals.md`: XTSMGRAPHICS entry beside Sixel. - File the two implementation issues before opening the PR so the matrix can cite their numbers (title style `[v0.1/Protocol] Implement …`, body: what, where in the parser/grid/daemon path, snapshot tests to add, esctest movement if any; end with "Split from #181."). ## Tests None beyond `just prose-check` and the docs-tree guards; the doc-cascade grep sweep for `DECCARA`, `2048`, `XTSMGRAPHICS` across `docs/`. ## Cascade `CHANGELOG.md` is not touched (no behavior change yet). `docs/reference/spec.md` only if a REQ cites the matrix rows.

natsukium added the

status/planned

label

2026-09-07 16:31:33 +09:00

natsukium referenced this issue

2026-09-07 16:33:18 +09:00

[v0.1/Protocol] Implement DECCARA / DECRARA rectangular attribute ops #188

natsukium referenced this issue

2026-09-07 16:33:18 +09:00

[v0.1/Protocol] Implement in-band resize notify (?2048) #189

natsukium referenced this issue from a commit

2026-09-07 16:37:42 +09:00