test: pin the OSC 4/5 refusal and OSC 13-19 no-op behavior at the dispatch layer #201

New issue

Closed

opened 2026-09-07 21:47:49 +09:00 by natsukium · 0 comments

natsukium commented

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

Owner

docs/reference/protocols/vt-compliance.md now states normatively that a refused colorimetric spec through OSC 4/5 leaves the addressed slot unchanged and emits no reply, and that OSC 13-19 are accepted-and-ignored regardless of spec form. Both claims check out by reading the code (dispatch_osc_palette_set_or_query and dispatch_osc_dynamic_color continue on a None from parse_x_color in crates/felis-grid/src/osc_dispatch.rs, and codes 13-19 fall through the _ => {} arm in crates/felis-grid/src/sink.rs's OSC match), but no test in the tree exercises either path.

crates/felis-grid/src/osc_color/tests.rs only pins rejection at the parser layer (parse_x_color returning None for CIELab/rgbi text). Grepping crates/felis-grid/tests/ and crates/felis-grid/src/ turns up no OSC 4/5 dispatch test that sends a rejected spec and asserts the existing slot value is preserved with no reply emitted, nor any test sending OSC 13-19 and asserting no state change and no reply.

The documented dispatch-level guarantee is therefore unpinned at the layer where it matters: a future change to the continue/no-op branches in osc_dispatch.rs would silently violate the documented contract with no test failing.

Correction: add a dispatch-level test (or extend an existing OSC 4/5 integration test) asserting that a refused colorimetric spec (e.g. \x1b]4;0;CIELab:1/1/1\x1b\\) leaves a previously-set slot's value unchanged and produces no OSC reply, plus a companion test that an OSC 13-19 sequence with any spec form produces no state change and no reply.

Deferred from #182 because the existing parser-layer test covers the rejection and that issue's plan called for no new tests; the dispatch-level gap is real but orthogonal to recording the non-goal.

Split from #182.

`docs/reference/protocols/vt-compliance.md` now states normatively that a refused colorimetric spec through OSC 4/5 leaves the addressed slot unchanged and emits no reply, and that OSC 13-19 are accepted-and-ignored regardless of spec form. Both claims check out by reading the code (`dispatch_osc_palette_set_or_query` and `dispatch_osc_dynamic_color` `continue` on a `None` from `parse_x_color` in `crates/felis-grid/src/osc_dispatch.rs`, and codes 13-19 fall through the `_ => {}` arm in `crates/felis-grid/src/sink.rs`'s OSC match), but no test in the tree exercises either path. `crates/felis-grid/src/osc_color/tests.rs` only pins rejection at the parser layer (`parse_x_color` returning `None` for CIELab/rgbi text). Grepping `crates/felis-grid/tests/` and `crates/felis-grid/src/` turns up no OSC 4/5 dispatch test that sends a rejected spec and asserts the existing slot value is preserved with no reply emitted, nor any test sending OSC 13-19 and asserting no state change and no reply. The documented dispatch-level guarantee is therefore unpinned at the layer where it matters: a future change to the `continue`/no-op branches in `osc_dispatch.rs` would silently violate the documented contract with no test failing. Correction: add a dispatch-level test (or extend an existing OSC 4/5 integration test) asserting that a refused colorimetric spec (e.g. `\x1b]4;0;CIELab:1/1/1\x1b\\`) leaves a previously-set slot's value unchanged and produces no OSC reply, plus a companion test that an OSC 13-19 sequence with any spec form produces no state change and no reply. Deferred from #182 because the existing parser-layer test covers the rejection and that issue's plan called for no new tests; the dispatch-level gap is real but orthogonal to recording the non-goal. Split from #182.

natsukium referenced this issue

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

docs: record colorimetric color specs as a non-goal #202

natsukium added the

priority/P2

type/test-gap

labels

2026-09-08 01:35:03 +09:00

natsukium referenced this issue from a pull request that will close it,

2026-09-08 01:52:23 +09:00

grid: pin the refused color spec at the OSC dispatch layer #216

natsukium referenced this issue from a commit