natsukium/felis
Watch
1
Code Issues 27 Pull requests 1 Projects Releases Packages Wiki Activity Actions

[v0.1/Protocol Review] Freeze the accepted-and-ignored / stub reply set #183

New issue
Closed
opened 2026-09-07 15:53:50 +09:00 by natsukium · 1 comment
natsukium commented 2026-09-07 15:53:50 +09:00
Owner
Copy link

Background

support-matrix.md carries a set of ⚠️ accepted and ignored / parsed but no-op / stubbed rows: compatibility shims that consume producer bytes without effect. Each one is individually reasonable, but as a set it is not frozen anywhere: there is no recorded list of what felis silently swallows, so a future addition (one more ignored OSC, one more stubbed query) lands without a decision. Since publish freezes observable behavior, freeze the set now — while removals are still free.

The current set (all in support-matrix.md)

Row Behavior
X10 mouse ?9 (:97) accepted and ignored
Legacy UTF-8 ?1005 / URXVT ?1015 (:98) accepted and ignored (SGR ?1006 is the supported encoding)
OSC 13–19 highlight/pointer/Tektronix colors (:122) accepted and ignored
OSC 633 shell integration (:123) accepted and ignored (OSC 133 is the supported form)
iTerm2 OSC 1337 non-image subcommands (:133) accepted and ignored
SCS charset selection (:159) parsed but no-op (use Unicode)
Blink (:86) parsed, never rendered (accessibility); fast→slow
Pixel-size CSI 14/15/16 t (:152) stubbed 0;0
DECRQM for unimplemented ANSI modes (:145) answers Ps=0 (unknown); only IRM/LNM report state
DECRQSS for unkept settings (vt-compliance.md) answers invalid 0$r
Status display DECSASD/DECSSDT, DECSNLS/DECSLPP (esctest-compatibility.md rejected cases) consumed and dropped; queries answer 0$r

Questions to settle

  1. Is the set closed? Each row pairs an ignored input with the supported alternative (?1006, OSC 133, Unicode). New ignore-rows should require the same pairing — record that rule in landscape.md so "just ignore it" stops being a no-decision default.
  2. Are the stub replies (0;0, Ps=0, 0$r) the frozen answers? They are what producers will branch on. vt-compliance.md "Reporting and queries" specifies exact reply payloads for supported queries; the stub answers deserve the same normative table so a future change to them is a breaking change, not a tweak.
  3. Blink: parsed-never-rendered with fast→slow mapping is an accessibility stance (support-matrix.md:86). It sits beside cursor blink config and the OS reduced-motion question (#122 open). Confirm the three agree before freeze.
  4. Anything to delete instead? Dropping an ignore-shim is breaking for the producer that emits it, but pre-publish that cost is zero. If any row survives only from development caution (e.g. X10 ?9 — does any real producer still need it swallowed vs refused?), now is the cheapest time to cut it.

Proposal

  • Add one "Consumed without effect" table to docs/reference/protocols/vt-compliance.md (normative: exact input → exact reply/no-op), covering every row above.
  • Add the pairing rule to docs/explanation/protocols/landscape.md: an ignore-row is accepted only beside its supported alternative, with a Revisit trigger.
  • Cross-check blink against #122 (OS reduced-motion) and the cursor-blink config so the three tell one story.
  • Anything cut in (4) is a pre-publish break: note it in CHANGELOG.md Unreleased.

Acceptance criteria

  • Every silently-swallowed input has exactly one normative row (input → reply/no-op) in vt-compliance.md.
  • landscape.md states the rule for adding future ignore-rows.
  • Blink behavior, #122, and cursor-blink config agree (or the disagreement is a tracked issue).

Sources reviewed

  • docs/reference/protocols/support-matrix.md (rows cited above)
  • docs/reference/protocols/vt-compliance.md ("Reporting and queries", rectangular editing notes on DECRQSS)
  • docs/reference/esctest-compatibility.md (9 rejected cases)
  • docs/explanation/protocols/landscape.md (no closed-set rule found)
  • #122 (OS reduced-motion query for cursor blink, open)
## Background `support-matrix.md` carries a set of `⚠️ accepted and ignored` / `parsed but no-op` / `stubbed` rows: compatibility shims that consume producer bytes without effect. Each one is individually reasonable, but as a *set* it is not frozen anywhere: there is no recorded list of what felis silently swallows, so a future addition (one more ignored OSC, one more stubbed query) lands without a decision. Since publish freezes observable behavior, freeze the set now — while removals are still free. ## The current set (all in `support-matrix.md`) | Row | Behavior | | --- | --- | | X10 mouse `?9` (`:97`) | accepted and ignored | | Legacy UTF-8 `?1005` / URXVT `?1015` (`:98`) | accepted and ignored (SGR `?1006` is the supported encoding) | | OSC 13–19 highlight/pointer/Tektronix colors (`:122`) | accepted and ignored | | OSC 633 shell integration (`:123`) | accepted and ignored (OSC 133 is the supported form) | | iTerm2 OSC 1337 non-image subcommands (`:133`) | accepted and ignored | | SCS charset selection (`:159`) | parsed but no-op (use Unicode) | | Blink (`:86`) | parsed, never rendered (accessibility); fast→slow | | Pixel-size `CSI 14/15/16 t` (`:152`) | stubbed `0;0` | | DECRQM for unimplemented ANSI modes (`:145`) | answers `Ps=0` (unknown); only IRM/LNM report state | | DECRQSS for unkept settings (`vt-compliance.md`) | answers invalid `0$r` | | Status display DECSASD/DECSSDT, DECSNLS/DECSLPP (`esctest-compatibility.md` rejected cases) | consumed and dropped; queries answer `0$r` | ## Questions to settle 1. **Is the set closed?** Each row pairs an ignored input with the *supported* alternative (`?1006`, OSC 133, Unicode). New ignore-rows should require the same pairing — record that rule in `landscape.md` so "just ignore it" stops being a no-decision default. 2. **Are the stub replies (`0;0`, `Ps=0`, `0$r`) the frozen answers?** They are what producers will branch on. `vt-compliance.md` "Reporting and queries" specifies exact reply payloads for supported queries; the stub answers deserve the same normative table so a future change to them is a breaking change, not a tweak. 3. **Blink**: parsed-never-rendered with fast→slow mapping is an accessibility stance (`support-matrix.md:86`). It sits beside `cursor blink` config and the OS reduced-motion question (`#122` open). Confirm the three agree before freeze. 4. **Anything to delete instead?** Dropping an ignore-shim is breaking for the producer that emits it, but pre-publish that cost is zero. If any row survives only from development caution (e.g. X10 `?9` — does any real producer still need it swallowed vs refused?), now is the cheapest time to cut it. ## Proposal - Add one "Consumed without effect" table to `docs/reference/protocols/vt-compliance.md` (normative: exact input → exact reply/no-op), covering every row above. - Add the pairing rule to `docs/explanation/protocols/landscape.md`: an ignore-row is accepted only beside its supported alternative, with a Revisit trigger. - Cross-check blink against `#122` (OS reduced-motion) and the cursor-blink config so the three tell one story. - Anything cut in (4) is a pre-publish break: note it in `CHANGELOG.md` Unreleased. ## Acceptance criteria - [ ] Every silently-swallowed input has exactly one normative row (input → reply/no-op) in `vt-compliance.md`. - [ ] `landscape.md` states the rule for adding future ignore-rows. - [ ] Blink behavior, `#122`, and cursor-blink config agree (or the disagreement is a tracked issue). ## Sources reviewed - `docs/reference/protocols/support-matrix.md` (rows cited above) - `docs/reference/protocols/vt-compliance.md` ("Reporting and queries", rectangular editing notes on DECRQSS) - `docs/reference/esctest-compatibility.md` (9 rejected cases) - `docs/explanation/protocols/landscape.md` (no closed-set rule found) - `#122` (OS reduced-motion query for cursor blink, open)
natsukium commented 2026-09-07 16:31:32 +09:00
Author
Owner
Copy link

Triage plan (2026-09-07)

Decision (user, 2026-09-07): adopt as proposed. The set is frozen as it stands; nothing is cut (the X10 ?9 shim stays: refusing it would only turn a harmless no-op into a stray-bytes hazard for an old producer).

Approach

Docs-only PR:

  • docs/reference/protocols/vt-compliance.md: one normative "Consumed without effect" table, one row per input in the issue's list, columns: input, exact reply (or "none"), the supported alternative. Stub replies (0;0, Ps=0, 0$r) are stated as the frozen answers.
  • docs/explanation/protocols/landscape.md: the pairing rule (an ignore-row is accepted only beside its supported alternative) with a "Revisit if …" trigger.
  • Blink: verify that support-matrix.md:86, the cursor-blink config key reference, and #122's premise tell one story; if they disagree, correct the doc that is wrong and cite #122 rather than opening a new issue.
  • support-matrix.md rows link to the new table rather than repeating the reply text.

Tests

just prose-check; the docs-tree guards; and, if felis-vt has a unit test per stub reply, cite the test name in the table so the normative row is executable. Do not add tests for behavior that already has one.

Cascade

No CHANGELOG entry (nothing cut). Grep sweep: accepted and ignored, stubbed, 0$r, parsed but across docs/.

## Triage plan (2026-09-07) **Decision (user, 2026-09-07): adopt as proposed.** The set is frozen as it stands; nothing is cut (the X10 `?9` shim stays: refusing it would only turn a harmless no-op into a stray-bytes hazard for an old producer). ## Approach Docs-only PR: - `docs/reference/protocols/vt-compliance.md`: one normative "Consumed without effect" table, one row per input in the issue's list, columns: input, exact reply (or "none"), the supported alternative. Stub replies (`0;0`, `Ps=0`, `0$r`) are stated as the frozen answers. - `docs/explanation/protocols/landscape.md`: the pairing rule (an ignore-row is accepted only beside its supported alternative) with a "Revisit if …" trigger. - Blink: verify that `support-matrix.md:86`, the cursor-blink config key reference, and #122's premise tell one story; if they disagree, correct the doc that is wrong and cite #122 rather than opening a new issue. - `support-matrix.md` rows link to the new table rather than repeating the reply text. ## Tests `just prose-check`; the docs-tree guards; and, if felis-vt has a unit test per stub reply, cite the test name in the table so the normative row is executable. Do not add tests for behavior that already has one. ## Cascade No CHANGELOG entry (nothing cut). Grep sweep: `accepted and ignored`, `stubbed`, `0$r`, `parsed but` across `docs/`.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
ci/darwin-smoke
No results found.
Labels
Clear labels   
priority/P0
Must be resolved before the v0.1.0 tag

  
priority/P1
Must be settled before the first public contract freezes

  
priority/P2
Explicitly deferred until after v0.1.0

  
release/v0.1.0
Work tracked for the first tagged release

  
status/blocked
Cannot start now: waits on an upstream release, another issue, or a recorded revisit trigger

  
status/planned
Triaged with a source-grounded plan and a passed pi review; ready to implement

  
type/bug
Shipped behavior that contradicts the docs or the code's own intent; needs a product code change

  
type/design
An open scope or trade-off question; needs a recorded decision in the owning explanation doc before code

  
type/test-gap
Documented or reviewed behavior that no test pins; usually split from a review finding, needs no product code change

  
type/tracker
Parent issue that tracks child work

No labels
priority/P0
priority/P1
priority/P2
release/v0.1.0
status/blocked
status/planned
type/bug
type/design
type/test-gap
type/tracker
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
natsukium/felis#183
No description provided.