v2 - WindowsDriver isn't render well on conhost terminal size.

[BDisp]

The right edge is cutting off.

VsDebugConsole_2RYejQxpV3.mp4

[a-usr]

It looks like something is Triggering the Terminal scrollbar to show up. Or the scrollbar doesnt have time to vanish in time?

[BDisp]

It looks like something is Triggering the Terminal scrollbar to show up. Or the scrollbar doesnt have time to vanish in time?

Because ANSI escape sequences for enable/disable alternative screen buffer were also sending to the conhost. Only Windows Terminal can handle it.

[a-usr]

Good to know! and I suppose the alternative screen buffer has better performance than the default one? Just curious.
Edit: I just googled it. So there is no need to answer my question anymore. But still its an interesting Feature! I do wonder however if it is possible to automatically detect the current Terminal Emulator.

[BDisp]

Terminal.Gui/Terminal.Gui/ConsoleDrivers/WindowsDriver.cs

Line 801 in e16205a

_isWindowsTerminal = Environment.GetEnvironmentVariable ("WT_SESSION") != null;

When run directly from Windows Terminal the "WT_SESSION" env will have a GUID, otherwise is empty.

[a-usr]

Another Interesting Fact! Two in a row! However it appears there isnt a standard for this, wich is kind of sad. I suppose its about time for someone to create a new Terminal Emulator standard, as, as per my understanding, the only reason the current one still exists is for backwards compatibility with actual Terminal Hardware. As always, if im wrong you are more than welcome to correct me (Seriously. I want to be Corrected. I'd rather be annoyed by someone correcting me in a extremely nerdy manner, than claim wrong things to be true for ethernety).

[BDisp]

@tig is already working on a new Terminal Emulator on PR #2940, which only will true color on Windows Terminal, because legacy Win32 API won't work with ANSI escape sequences without Windows Terminal. The only exception is the NetDriver which works with ANSI escape sequences on more terminal because it use .NET System.Console, but is very slower on Windows.
But remember that I'm a nerd explaining this 😃.

[a-usr]

I believe you meant to say Console Driver instead of Terminal emulator.

Im not sure if you know about this, but way back before computers where directly connected to screen, mouse and keyboard, the only way to interact with them ( or rather their programs ) was through so called Terminals, wich where connected to the computers through a serial connection (i believe) and consisted of a screen, keyboard and a small Logic unit that handled sending user input and rendering received characters to the screen.

Back then the computer (or rather the programs executed on it) could interact directly with the terminal using the ANSI escape codes you mentioned. One such Terminal was the VT 340 (wikipedia).

Modern apps like the old Conhost.exe, Windows Terminal or xterm try to emulate the behaviour of such terminals, wich is why they fall under the category of Terminal Emulators.

Assuming that @tig was born some years before 1987 ( source ) he is probably able to tell you way more about physical/hardware terminals than i ever could, as my only source is online articles and a Github repository