[v0.1/Protocol Review] Decide the colorimetric-transform deferral (21 esctest cases) #182

New issue

Closed

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

natsukium commented

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

Owner

Background

21 of the 34 tracked esctest failures are colorimetric color-spec transforms (docs/reference/esctest-compatibility.md "Deferred cases"): CIELab, CIELuv, CIEXYZ, CIExyY, CIEuvY, RGBI, and TekHVC variants across the ChangeColor families (OSC 4 / 5 / 10–19). The docs say they "require per-space matrix and gamma transforms in crates/felis-grid/src/osc_color.rs". No issue tracks this work (searched colorimetric, osc_color: zero hits).

Current state: rgb: and #hex forms are ✅ (support-matrix.md:150-152); every colorimetric space is deferred. crates/felis-grid/src/osc_color.rs owns parse_x_color / format_osc_color_response, wired through osc_dispatch.rs.

Why this needs a decision before publish

The deferred-cluster list in esctest-compatibility.md accounts for every remaining failure, so the gate is satisfied either way. What is missing is the stance: is full color-space support on the roadmap (maximalism inside the screen per feature-baseline.md), or is rgb:/#hex the committed subset with the rest a non-goal?
Real producers (colormap-heavy TUIs, ChangColor-emitting tools) will hit this. If the answer is "defer", consumers deserve a recorded subset statement in reference/protocols/vt-compliance.md, not just an esctest-cluster label.
If the answer is "implement", the work is bounded and well-specified: per-space matrices + gamma in one module, snapshot tests over OSC 4/5/10–19, and a 21-case esctest movement that raises PASS_BASELINE per how-to/update-esctest-baseline.md.

Proposal

Decide implement vs non-goal for colorimetric specs, and record it:
- Implement → file the implementation issue (matrices + gamma in osc_color.rs, snapshots, esctest ratchet). The 21 cases become the acceptance list.
- Non-goal → flip the three ⚠️ rows in support-matrix.md to state the committed subset explicitly (rgb:/#hex supported; colorimetric spaces rejected), add the rationale to explanation/protocols/vt-compliance.md (conscious omissions live there, cf. DECCOLM), and re-label the esctest cluster from "deferred" to "rejected".
Either way, link the tracking/decision issue number from esctest-compatibility.md so the cluster list is not a dead end.

Acceptance criteria

esctest-compatibility.md's colorimetric cluster points at a decision (implementation issue or non-goal record), not just a module path.
support-matrix.md OSC 4/5/10–19 rows state the committed subset without needing the esctest page to interpret them.
If implemented: PASS_BASELINE raised by the fixed cases in the same commit (ratchet rule).

Sources reviewed

docs/reference/esctest-compatibility.md "Deferred cases (25 tests)" — 21 colorimetric
docs/reference/protocols/support-matrix.md:150-152 (OSC 4/5/10–19 rows)
crates/felis-grid/src/osc_color.rs, crates/felis-grid/src/osc_dispatch.rs
docs/explanation/feature-baseline.md (maximalism inside the screen)
Issue search: colorimetric, osc_color — no tracking issue exists

## Background 21 of the 34 tracked esctest failures are colorimetric color-spec transforms (`docs/reference/esctest-compatibility.md` "Deferred cases"): `CIELab`, `CIELuv`, `CIEXYZ`, `CIExyY`, `CIEuvY`, `RGBI`, and `TekHVC` variants across the ChangeColor families (OSC 4 / 5 / 10–19). The docs say they "require per-space matrix and gamma transforms in `crates/felis-grid/src/osc_color.rs`". No issue tracks this work (searched `colorimetric`, `osc_color`: zero hits). Current state: `rgb:` and `#hex` forms are `✅` (`support-matrix.md:150-152`); every colorimetric space is deferred. `crates/felis-grid/src/osc_color.rs` owns `parse_x_color` / `format_osc_color_response`, wired through `osc_dispatch.rs`. ## Why this needs a decision before publish - The deferred-cluster list in `esctest-compatibility.md` accounts for every remaining failure, so the gate is satisfied either way. What is missing is the *stance*: is full color-space support on the roadmap (maximalism inside the screen per `feature-baseline.md`), or is `rgb:`/`#hex` the committed subset with the rest a non-goal? - Real producers (colormap-heavy TUIs, `ChangColor`-emitting tools) will hit this. If the answer is "defer", consumers deserve a recorded subset statement in `reference/protocols/vt-compliance.md`, not just an esctest-cluster label. - If the answer is "implement", the work is bounded and well-specified: per-space matrices + gamma in one module, snapshot tests over OSC 4/5/10–19, and a 21-case esctest movement that raises `PASS_BASELINE` per `how-to/update-esctest-baseline.md`. ## Proposal - Decide implement vs non-goal for colorimetric specs, and record it: - Implement → file the implementation issue (matrices + gamma in `osc_color.rs`, snapshots, esctest ratchet). The 21 cases become the acceptance list. - Non-goal → flip the three `⚠️` rows in `support-matrix.md` to state the committed subset explicitly (`rgb:`/`#hex` supported; colorimetric spaces rejected), add the rationale to `explanation/protocols/vt-compliance.md` (conscious omissions live there, cf. DECCOLM), and re-label the esctest cluster from "deferred" to "rejected". - Either way, link the tracking/decision issue number from `esctest-compatibility.md` so the cluster list is not a dead end. ## Acceptance criteria - [ ] `esctest-compatibility.md`'s colorimetric cluster points at a decision (implementation issue or non-goal record), not just a module path. - [ ] `support-matrix.md` OSC 4/5/10–19 rows state the committed subset without needing the esctest page to interpret them. - [ ] If implemented: `PASS_BASELINE` raised by the fixed cases in the same commit (ratchet rule). ## Sources reviewed - `docs/reference/esctest-compatibility.md` "Deferred cases (25 tests)" — 21 colorimetric - `docs/reference/protocols/support-matrix.md:150-152` (OSC 4/5/10–19 rows) - `crates/felis-grid/src/osc_color.rs`, `crates/felis-grid/src/osc_dispatch.rs` - `docs/explanation/feature-baseline.md` (maximalism inside the screen) - Issue search: `colorimetric`, `osc_color` — 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)

Decision (user, 2026-09-07): non-goal. rgb: and #hex are the committed color-spec subset; the CIE / RGBI / TekHVC spaces are rejected. kitty does not implement them either, and no producer felis targets emits them; the 21 esctest cases are xterm's coverage of xterm's own extension, not a compatibility gap a user will hit.

Approach

Docs-only PR:

docs/reference/protocols/support-matrix.md: the OSC 4 / 5 / 10–19 rows state the subset explicitly (rgb: and #hex accepted; colorimetric color spaces refused, reply omitted) so the row reads without the esctest page.
docs/explanation/protocols/vt-compliance.md (conscious omissions, beside DECCOLM): the rationale above plus a "Revisit if …" trigger (a producer in the supported set starts emitting a colorimetric spec).
docs/reference/esctest-compatibility.md: move the 21 cases from "Deferred" to "Rejected" with this issue as the decision record; PASS_BASELINE unchanged.
docs/explanation/non-goals.md: one entry.
If crates/felis-grid/src/osc_color.rs carries a comment promising future color-space support, replace it with a pointer to the decision (prune-comments rule: no history, no roadmap).

Tests

None beyond just prose-check, the docs-tree guards, and the esctest baseline test (the count of tracked failures must still reconcile).

Cascade

Grep sweep: colorimetric, CIELab, TekHVC, osc_color across docs/. No CHANGELOG entry (no behavior change).

## Triage plan (2026-09-07) **Decision (user, 2026-09-07): non-goal.** `rgb:` and `#hex` are the committed color-spec subset; the CIE / RGBI / TekHVC spaces are rejected. kitty does not implement them either, and no producer felis targets emits them; the 21 esctest cases are xterm's coverage of xterm's own extension, not a compatibility gap a user will hit. ## Approach Docs-only PR: - `docs/reference/protocols/support-matrix.md`: the OSC 4 / 5 / 10–19 rows state the subset explicitly (`rgb:` and `#hex` accepted; colorimetric color spaces refused, reply omitted) so the row reads without the esctest page. - `docs/explanation/protocols/vt-compliance.md` (conscious omissions, beside DECCOLM): the rationale above plus a "Revisit if …" trigger (a producer in the supported set starts emitting a colorimetric spec). - `docs/reference/esctest-compatibility.md`: move the 21 cases from "Deferred" to "Rejected" with this issue as the decision record; `PASS_BASELINE` unchanged. - `docs/explanation/non-goals.md`: one entry. - If `crates/felis-grid/src/osc_color.rs` carries a comment promising future color-space support, replace it with a pointer to the decision (prune-comments rule: no history, no roadmap). ## Tests None beyond `just prose-check`, the docs-tree guards, and the esctest baseline test (the count of tracked failures must still reconcile). ## Cascade Grep sweep: `colorimetric`, `CIELab`, `TekHVC`, `osc_color` across `docs/`. No CHANGELOG entry (no behavior change).

natsukium added the

status/planned

label

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

natsukium referenced this issue from a commit

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

ci: keep Windows and Darwin checks satisfiable on docs-only changes

natsukium referenced this issue

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

ci: keep Windows and Darwin checks satisfiable on docs-only changes #190

natsukium referenced this issue

2026-09-07 21:47:49 +09:00