grid: adopt in-band resize notify (?2048) #214

Merged

natsukium merged 3 commits from feat/in-band-resize-189 into main 2026-09-08 01:35:00 +09:00

Conversation 0 Commits 3 Files changed 8 +333 -10

natsukium commented 2026-09-08 01:19:47 +09:00

Owner

Copy link

Fixes #189.

Implements in-band resize notification (DECSET/DECRST ?2048), so a program that
opts in learns about every geometry change from the terminal itself instead of
racing SIGWINCH against its own reads.

• felis-grid tracks the mode as grid state, exposes it through the sink, and
  answers DECRQM for it.
• The daemon reports once immediately when a program sets the mode, and then on
  every geometry change while the mode stays set — the report rides the same PTY
  write path as the rest of the reply traffic.
• Clearing the mode stops the reports; the shipped default is off.

Doc cascade: docs/reference/protocols/vt-compliance.md and
docs/reference/protocols/support-matrix.md move ?2048 out of the
consumed-without-effect set and state the shipped behavior; CHANGELOG.md records
the user-affecting default.

Verified: just check green (fmt, clippy, nextest, deny, proto-compat); reviewed by
pi luna + pi sol; docs proofread by Gemini gemini-3.8-flash-high

Follow-ups

• #213 test: no daemon test drives DECSET 2048 through the real parser/drain_effects/reconcile wiring

Deferred

• esctest baseline ratchet — esctest has no ?2048 coverage, so PASS_BASELINE does not move.
• A fuzz seed for \x1b[?2048h — the mode arm adds no new parse shape: one more integer in the existing DECSET dispatch, already covered by the parser totality proptest and the existing fuzz targets.
• skills/felis/SKILL.md — no CLI or IPC surface changed; the mode is terminal-side only.

Fixes #189. Implements in-band resize notification (DECSET/DECRST `?2048`), so a program that opts in learns about every geometry change from the terminal itself instead of racing `SIGWINCH` against its own reads. - `felis-grid` tracks the mode as grid state, exposes it through the sink, and answers DECRQM for it. - The daemon reports once immediately when a program sets the mode, and then on every geometry change while the mode stays set — the report rides the same PTY write path as the rest of the reply traffic. - Clearing the mode stops the reports; the shipped default is off. Doc cascade: `docs/reference/protocols/vt-compliance.md` and `docs/reference/protocols/support-matrix.md` move `?2048` out of the consumed-without-effect set and state the shipped behavior; `CHANGELOG.md` records the user-affecting default. Verified: just check green (fmt, clippy, nextest, deny, proto-compat); reviewed by pi luna + pi sol; docs proofread by Gemini gemini-3.8-flash-high ## Follow-ups - #213 test: no daemon test drives DECSET 2048 through the real parser/drain_effects/reconcile wiring ## Deferred - esctest baseline ratchet — esctest has no `?2048` coverage, so `PASS_BASELINE` does not move. - A fuzz seed for `\x1b[?2048h` — the mode arm adds no new parse shape: one more integer in the existing DECSET dispatch, already covered by the parser totality proptest and the existing fuzz targets. - `skills/felis/SKILL.md` — no CLI or IPC surface changed; the mode is terminal-side only.

natsukium added 3 commits 2026-09-08 01:19:47 +09:00

grid: adopt in-band resize notify (?2048) ... b43800c7b9

felis's PTY geometry moves from directions a program cannot observe —
a window resize, a `window retarget`, a second attached client taking
the size — and SIGWINCH answers none of them in order against the
input around it. So the mode is recorded here and reported by the
daemon, the set's own answer included: a report the grid queued into
the parse-effect queue would carry the geometry that was live when the
set was parsed, which a resize written straight to the PTY can
overtake.

The pixel axes carry the `0` stub `CSI 14 t` answers: window extents
are one window's fact and the grid is shared by every mirror of the
session, so the notification never widens what a program can learn
about the host.

Refs #189

daemon: notify ?2048 programs on every geometry change ... 416ac35de3

Only the daemon knows when a resize landed, and it owns the PTY
writer, so it is the single emitter: the set's own answer and every
later report are one path, compared against the geometry the program
was last told. Two emitters would double-report one geometry, since
the grid's mode flag and the daemon's resize edge are set by different
threads with no ordering between them.

The write is deferred to the run loop's reconcile like the focus and
scheme reports, because `apply_size` runs on sync paths that have no
way to carry a PTY error out. Input that transfers size ownership is
the exception: it reports before writing its own bytes, or the program
would see the keystroke that implied the new geometry ahead of the
geometry.

Refs #189

docs: state in-band resize notify as shipped ... 9d2653b387

The stance and its rationale were already recorded in the protocol
landscape; what was missing is the normative shape a program can code
against and the status row it looks the mode up in.

Refs #189

natsukium merged commit 9d2653b387 into main 2026-09-08 01:35:00 +09:00

natsukium deleted branch feat/in-band-resize-189 2026-09-08 01:35:00 +09:00

Sign in to join this conversation.

Reviewers

No reviewers

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

Subscribe

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!214

No description provided.