GetConsoleScreenBufferInfo() returns very different terminal height in CMD vs Windows new Terminal app

[tartley]

Reported by the industrious LqdBcnAtWork at #352 (comment):

Another quirk with colorama.win32.GetConsoleScreenBufferInfo().

In Windows default CMD prompt, running str(colorama.win32.GetConsoleScreenBufferInfo()) yields something like:

'(9001,120,56,0,7,27,0,56,119,63,120)'

Those first two numbers are the terminal height (including all scrollback) and width. However calling the same function in the fancy new Terminal app for win10, gives a very different result:

'(52,209,51,0,7,0,0,51,208,52,209)'.

The terminal height is much smaller. It is just actual visible space for text, no matter how much you can scroll back by.

Now this is an issue because the CMD reports the cursor position from it's zero, while the Terminal reports the cursor position within the screen, but both translate the ANSI calls to be relative to the screen.

Example scenario

So, for example, in my scenario, I have a function that'll print n lines, move back up, n lines, then save the cursor position for printing/reprinting a line. This is so I can specify the amount of lines I may or may not print (but not track) before scrolling would happen. That way I can return to a line and update it's contents without worrying about having to know exactly how many lines have been printed. But I need to handle this in both CMD and the Terminal.

A workaround

Fortunately colorama.win32.GetConsoleScreenBufferInfo().srWindow.Top reports correctly for both, so I just get the Y value for the cursor, and subtract that Top value from it, and add 1. That way I always get an accurate value for the cursor's line.

Windows console, always causing issues because it's different.

[tartley]

Including this reported quirk as an issue here, so that at least users can search for it and find the workaround.