Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
getTerminalSize assumes 999x999 max #97
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.
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.