fix(pty): refuse a degenerate terminal size instead of honouring it - #52
Merged
Conversation
Found while verifying F-04 in a real browser, not by review. The xterm fit addon measures its container. A tab that has not been laid out yet, or a pane that is briefly zero-width, makes it compute `cols: 1` and send it. `_bounded` accepted anything from 1 to MAX_DIMENSION, so the PTY was duly resized to one column and every prompt after that wrapped one character per line. What made it hard to recognise: the Rich banner is printed at spawn, before the resize frame arrives, so it stays perfectly readable at 100 columns while everything after it is a vertical ribbon. It reads as a font or rendering fault rather than as a resize the server agreed to. The give-away was that the `.xterm-rows` first row was still 100 characters wide while the live prompt was not. Floored server-side at 20 columns rather than fixed in the client. The client is the thing that was wrong, and a bound that only holds when the client is correct is not a bound. 20 leaves room for the menu to be legible while still refusing anything that is obviously a measurement of nothing. One existing parametrised case asserted that 1 was usable. It is the assumption being corrected, so it is now MIN_DIMENSION with a note saying why. 842 py. black, ruff, mypy clean.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found while verifying F-04 in a real browser, not by review.
The xterm fit addon measures its container. A tab that has not been laid out
yet, or a pane that is briefly zero-width, makes it compute
cols: 1and sendit.
_boundedaccepted anything from 1 to MAX_DIMENSION, so the PTY was dulyresized to one column and every prompt after that wrapped one character per
line.
What made it hard to recognise: the Rich banner is printed at spawn, before the
resize frame arrives, so it stays perfectly readable at 100 columns while
everything after it is a vertical ribbon. It reads as a font or rendering fault
rather than as a resize the server agreed to. The give-away was that the
.xterm-rowsfirst row was still 100 characters wide while the live prompt wasnot.
Floored server-side at 20 columns rather than fixed in the client. The client is
the thing that was wrong, and a bound that only holds when the client is correct
is not a bound. 20 leaves room for the menu to be legible while still refusing
anything that is obviously a measurement of nothing.
One existing parametrised case asserted that 1 was usable. It is the assumption
being corrected, so it is now MIN_DIMENSION with a note saying why.
842 py. black, ruff, mypy clean.