Page-format controls DECSCPP and DECSLPP are ignored

[tomlm]

vttest menu 11 → 2 → 3, "Page Format Tests", judges these itself — it fills the page and reports how much of what it asked for it got:

DECSCPP:  Screen should be filled (80 of 80 columns)     ok
          Screen should be filled (80 of 132 columns)    <-- asked 132, got 80

DECSLPP:  Screen should be filled (24 of 24 rows)        ok
          Screen should be filled (24 of 25 rows)        <-- asked 25, got 24
          Screen should be filled (24 of 36 rows)
          Screen should be filled (24 of 48 rows)

Confirmed from the raw stream that the requests are actually sent: DECSCPP requests: ['', '80', '80', '132', ''], and no DECCOLM anywhere in that test — so this is DECSCPP on its own, not the 132-column path that already works.

Cause

DECSCPP (CSI Ps $ |) has no entry in the CSI identifier table — grep '$|' over CommandExtensions.cs returns nothing, so the sequence is parsed and dropped.

DECSLPP (CSI Ps t, Ps ≥ 24) reaches the window-operation switch, which handles up to case 23 (pop titles) and has nothing above it. CSI 25 t therefore falls through silently.

Expected

Both set the page size, and the emulator already knows how to resize itself — SetColumnMode does exactly this for DECCOLM, gated on Allow80To132.

One difference is worth getting right rather than reusing DECCOLM wholesale: DECCOLM clears the screen and DECSCPP does not. They are different controls with different side effects, and vttest's page-format test fills the screen and then checks it, so a clear would be visible as a failure of a different kind.

CSI Ps t is shared between DECSLPP and the dtterm window operations, and Ps ≥ 24 is the split — worth a comment where the switch grows the case, since the overlap is the sort of thing that gets "tidied" later.

Reproduction

wsl vttest
11    # Non-VT100 tests
2     # VT320 features
3     # page-format controls
1     # DECSCPP   (or 2 for DECSLPP)

[tomlm]

Half of this issue is withdrawn: DECSLPP was never broken.

CSI Ps t with Ps ≥ 24 has always resized — WindowManipulation handles it before the window-operation switch:

// Values of 24 and up are not window operations at all: they are DECSLPP ...
if (operation >= 24)
{
    _terminal.Resize(_terminal.Cols, operation);
    return;
}

Confirmed directly: 80x24 → CSI 25 t → 80x25 → CSI 48 t → 80x48, raising Resized each time.

What misled me was quoting vttest's Screen should be filled (24 of 25 rows) as evidence. That line is vttest's own view of the size, which it samples when a test starts and does not re-measure — not a statement about what the terminal did. The same line appears whether or not the resize worked, so it was never evidence either way, and it says the same thing about DECSCPP.

Two contributing mistakes on my side, both fixed:

• The sweep harness dumped a hardcoded 24 rows, so every row a resize added was invisible. It follows terminal.Rows now.
• I did not check whether a pty resize reaches a program inside WSL before blaming the emulator. It does — stty size across one shows 24 80 then 48 132.

DECSCPP was a real gap and that half stands: no $| entry in the CSI table, verified in source rather than inferred from vttest. Implemented in the VTTEST alignment PR, along with DECNCSM (#143), since all three are one method:

• DECCOLM erases.
• DECCOLM with DECNCSM set does not.
• DECSCPP never does.

Pinned by tests directly against the emulator, because vttest cannot check any of this through a pty.

[tomlm]

Both halves settled on merged main (6d32504), measured rather than assumed:

DECSCPP 132 -> 132 cols       DECSLPP 25 -> 25 rows

DECSCPP was the real gap — no $| entry in the CSI table — and is implemented in #141, along with DECNCSM (#143) since all three page-size controls are one method: DECCOLM erases, DECNCSM turns that off, DECSCPP never erases. It also declines widths it does not define now, rather than rounding CSI 999 $ | up to 132.

DECSLPP was never broken, and that half of this issue is withdrawn — see the comment above. CSI Ps t with Ps ≥ 24 has always resized. I had quoted vttest's Screen should be filled (24 of 25 rows) as evidence, and that line is vttest's own view of a size it samples once per test and never re-measures: it reads identically whether the resize worked or not.

Closing rather than leaving it open for the withdrawal to be read, since the withdrawal is recorded in the thread and in #141's description.