Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

getTerminalSize assumes 999x999 max #97

Open
joeyh opened this issue Oct 6, 2019 · 2 comments

Comments

@joeyh
Copy link

commented Oct 6, 2019

getTerminalSize is an impressive thing to be able to do within the constraints of ANSI. But, I noticed it hardcodes 999x999, and so wondered when it would fail. It seems that 16k monitors are now available with 15360×8640 pixel resolution. Assuming a minimum font size of 8 pixels is used, that well exceeds 999x999.

(Of course, 8 pixel text is likely too small to read with the naked eye on most such displays, but it's not unheard of to resize a terminal too small to read.)

While it seems that increasing it to 9999x9999 would keep ahead of display progress for a while, I wonder if it would instead be possible to avoid hardcoding an upper limit at all? I'm thinking something like, get the cursor position, move it down and right N places, check position again, and repeat as long as it continues to move.

@mpilgrem

This comment has been minimized.

Copy link
Collaborator

commented Oct 8, 2019

Thank you. Getting the cursor position is not straightforward (send command, flush output buffer, intercept results on standard input stream, parse results), so I consider that an algorithm that does that repeatedly is not attractive.

Increasing the 'very large' cursor position is a possibility - although I anticipate few people need software that is robust to users running it in a terminal window with more than 999 rows or more than 999 columns, given commercially-available monitor resolutions.

In that regard, the native Windows 10 terminals are limited to a theoretical position of 32,767 x 32,767. I suspect that other terminal software does not have a smaller constraint. If nobody identifies terminal software that cannot cope, I would be happy to bump 999x999 to the Windows maximum.

@joeyh

This comment has been minimized.

Copy link
Author

commented Oct 8, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.