Rows vanish from vttest's SI/SO screen after a 96-character G1 designation (ESC - A)

[JohnCampionJr]

vttest's Shift In/Shift Out test (menu 3 → "Test Shift In/Shift Out") draws two three-row charset blocks. The G0 block renders fully; of the G1 block — designated Latin-1 via the 96-character-set form ESC - A — only the third row (`…~) appears. Rows 8 and 9 (!"#…? and @A…_) never make it to the screen, though they are present in the stream:

ESC - A  ESC[8;10H !"#$%&'()*+,-./0123456789:;<=>?  ESC[9;10H@AB…^_  ESC[10;10H`ab…~ DEL

Actual screen: rows 8–9 blank, row 10 correct.

Mechanism not yet pinned — the designator that precedes the loss is the 96-set form (ESC - Ps for G1, vs ESC ) Ps for 94-sets), which suggests the parser mishandles that intermediate and eats or misroutes what follows. Adjacent to but distinct from #131: no single/locking shifts are involved, just SI/SO with a 96-set G1.

Found by replaying a captured vttest corpus; deterministic at the buffer level.

🤖 Generated with Claude Code

[tomlm]

Not reproducing from the sequence as quoted — on current code or on main.

Replayed exactly what the issue lists, into a bare Terminal with no vttest involved:

ESC - A
ESC[8;10H  !"#$%&'()*+,-./0123456789:;<=>?
ESC[9;10H @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
ESC[10;10H `abcdefghijklmnopqrstuvwxyz{|}~

row  7: '          !"#$%&'()*+,-./0123456789:;<=>?'
row  8: '         @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_'
row  9: '         `abcdefghijklmnopqrstuvwxyz{|}~'

All three rows land. I checked main in a separate worktree to rule out my own charset changes having fixed it incidentally — same result there, so it was never the 96-set designator on its own.

Live vttest agrees: menu 3 → "Test Shift In/Shift Out" renders both three-row blocks complete here.

So the mechanism is something else in the captured corpus — preceding state rather than that designation. Worth checking whether the capture had NRC mode on, a DECSCL level set, or a # somewhere in the missing rows, since the designator collision is real even though it does not lose rows: A is the United Kingdom set after ESC ( and ISO Latin-1 after ESC -. Before this change the 96-set forms were not dispatched at all, so ESC - A left G1 as ASCII; had they been routed through the 94-set lookup instead, # would have silently become £.

That is fixed in the VTTEST alignment PR — ESC -, ESC . and ESC / are dispatched into their own identifier space now, with the two directions pinned by a test.

Leaving this open rather than closing it, since you saw something I cannot reproduce. If you still have the corpus, the bytes immediately before ESC - A are where I would look next — happy to replay a capture if you can attach one.

[JohnCampionJr]

Ugh. Confirmed. Claude read it wrong LOL

My report was an off-by-one: vttest numbers rows from 1, the buffer from 0, so what I called "rows 8–9 blank" was me reading buffer rows 8–9 (vttest 9–10) and the empty row past the block.

[JohnCampionJr]

You were right, and the fault is mine — closing this.

It was an off-by-one in how I read the buffer: vttest numbers its rows from 1, the buffer indexes from 0. What I reported as "rows 8–9 blank" was me looking at buffer rows 8–9 (vttest rows 9–10) plus the genuinely empty row past the block. Replaying the captured screen verbatim, all three rows are present on main and on the VTTEST alignment branch alike:

buffer 7:  !"#$%&'()*+,-./0123456789:;<=>?
buffer 8: @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
buffer 9: `abcdefghijklmnopqrstuvwxyz{|}~

That is vttest rows 8, 9 and 10 — the complete G1 block. Nothing was ever lost.

For the record, since you asked what preceded the designation: the captured bytes are ESC ) B ESC ( B SO ESC - A, so SO is active and GL is G1 when those rows are written — a different state from the repro in your comment, which left GL as G0. It turns out not to matter; both produce all three rows.

One observation I am deliberately not filing as an issue, because it is your call and I have already cost you a hunt: in both states, and on both branches, the G1 block stores plain ASCII (U+0021, U+0022, U+0023…) rather than Latin-1 (U+00A1, U+00A2, U+00A3…). Given the screen is captioned "Character set A (ISO Latin-1)", that may be what the test is actually checking — or invoking a 96-set into GL via SO may legitimately not translate, in which case there is nothing here either. You have vttest running and own this area, so I would rather hand you the observation than guess at it a second time.

Sorry for the noise.

[JohnCampionJr]

Following up the follow up - there is a small bug here:

There is a defect underneath it, just a smaller one: the escape dispatch at InputHandler.cs:906-925 handles only (, ), *, + and # as intermediates. The 96-character-set designators ESC -, ESC ., ESC / (G1/G2/G3) fall through and are dropped, so ESC - A leaves G1 as ASCII instead of Latin-1. That's "the designation is ignored", not "the parser eats what follows".

[JohnCampionJr]

Two corrections to this report, both from replaying it rather than from reading the code.

The rows do not vanish. The exact stream quoted above, replayed into a headless 80x24 terminal — and again with SO in front of it, which the quoted stream omits — puts all three rows on the screen at the right columns with the right text. The "mishandles that intermediate and eats or misroutes what follows" hypothesis is wrong; nothing after ESC - A is consumed. What the screen was really showing is a designation that had no effect, because ESC -, ESC . and ESC / were not dispatched at all.

That half is fixed on vttest-alignment by e0edfd5, which gives the 96-set designators their own space.

A second defect was left behind it, and this issue's title now names it. A is ISO Latin-1 in the 96-set space and the United Kingdom set in the 94-set one. That commit keeps the two apart at designation time, but stores the identifier without the space it came from — and DECNRCM re-resolves every stored identifier through the 94-set lookup:

• ESC - A, SO, print # gives #, correct
• ESC - A, DECNRCM set, SO, print # gives a pound sign, the UK set
• resetting DECNRCM again does not bring it back

Invisible in the screen this issue was filed against, because the difference between Latin-1 and UK across the whole ASCII range is that one character.

Fix in #146, stacked on #141.

[tomlm]

Re-checked against merged main (6d32504) — still not reproducing from the sequence as quoted:

#137 row 7: '          !"#$%&'()*+,-./0123456789:;<=>?'
#137 row 8: '         @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_'
#137 row 9: '         `abcdefghijklmnopqrstuvwxyz{|}~'

All three rows land. #141 did ship the adjacent fix — ESC -, ESC . and ESC / are dispatched now, into their own identifier space, so ESC - A designates ISO Latin-1 rather than falling through to ASCII (and is not mistaken for the UK set, which is what A means after ESC (). That is a real change to the path this issue names, so it is worth re-running your corpus against main before deciding what remains.

Leaving it open rather than closing it on my inability to reproduce: you saw rows vanish, and the mechanism was never pinned. If the corpus still shows it, the bytes immediately before ESC - A are where I would look — happy to replay a capture if you can attach one.

[JohnCampionJr]

Fixed in #150