Discussion: How to support different terminal environments

[chhackett]

Supporting terminals such as mintty or ConEmu correctly may be difficult.

Related discussion is happening on the Windows Terminal github:
microsoft/terminal#7434

[ShrykeWindgrace]

Tested alacritty, it almost works.

• blinking text does not work
• hiding cursor does not work

Otherwise everything seems to be Ok.

[chhackett]

Another alacritty problem: mouse mode doesn't work.
Apparently this is a known issue on Windows: alacritty/alacritty#1663
So we probably can't do anything about that. But hopefully we can detect that the environment doesn't support mouse mode and report it as not available.

I also tried running a git-bash shell. That doesn't work at all. App crashes with:
$ vty-mode-demo.exe
vty-mode-demo.exe: GetConsoleMode: invalid argument (The handle is invalid.)

I spent some time earlier trying to figure this out and have not made any progress yet.

[chhackett]

Perhaps we can use ALACRITTY_LOG env var to detect app is running in alacritty.

[ShrykeWindgrace]

I propose to track these issues as a table with the following info:

• OS (because win10 and win11 start to diverge)
• emulator (WT, old-school conhost, msys/mingw, cygwin, alacritty, wezterm, cmder, conemu, whatever is behind gitbash, and so on and so for)
• possibility to reliably detect these emulators by the app (not given)
• group known issues (attribute handling, color handling, mouse handling, cursor handling, etc) and possible workarounds
• relevant upstream issues/discussions

[ShrykeWindgrace]

Template is here: https://github.com/chhackett/vty-windows/wiki/TerminalSupport

I'll update it as the time goes

[chhackett]

Beautiful. I'll add as well.

[ShrykeWindgrace]

The problem with environment variables is that they are inherited. Say, I run WindowsTerminal (so its WT_SESSION is set), spawn a cmd.exe (separate legacy window), and from within spawn an alacritty (separate almost-new-school window). Now we have both WT_SESSION and ALACRITTY_LOG available.

Best I could think of is an early attempt to grab Windows Console Handle - if there is an exception, then the app will not work at all (with our current code), we catch that exception and gracefully stop - warn the user, show links to the list of supported terminals, etc.

Most importantly, we can do that prior to modifying anything in the terminal state, so we do not leave it in an incoherent state because of a crash.

If, on the other hand, we could grab that handle, we can proceed and hope that at least basic features will work. We still won't have a 100%-working way (only an approximation) to distinguish between e.g. WT and Alacritty, but that bug is slightly less important.

[ShrykeWindgrace]

Speaking of cygwin and its relatives (mintty emulator, the one spawned by git bash, msys2, and so on, if the windows setting is "let the CLI app pick its terminal emulator")

• unix package is explicitly not supported for cygwin usages
• it looks like mintty implements enough of features to be xterm-256color compatible
• if we skip all signal handling/subscription modifications, and retain only buffering tweaks, we should be able to adapt existing code in vty-unix (using only Handle without Fd/FD)
• I do not know whether some of the capabilities will be lost entirely - to tested=)

That being said, I do not have an ETA for the proof-of-concept.

[chhackett]

@ShrykeWindgrace
So I've been working on support for mintty/msys2 terminals the last few weeks. I have it mostly working except for two problems. Getting the current window size is turning out to be very difficult. I initially tried to use the ioctl system call to read the TIOCGWINSZ struct. This doesn't work because it seems that mintty/mingw does not provide an implementation of ioctl.
The next logical approach is what I have currently, which is to send the 'report screen size' escape sequence ("\ESC[18t"), then read the response escape sequence on stdin.

But this approach has failed. Even though the terminal is emitting the screen size sequence, the application is not reading it. Not sure why. But when I exit the application, I see the screen size sequence on the command line, like this:
$ ;43;131t;43;131t;43;131t

The second problem is that the terminal stops responding to vty output at some point. This may or may not have anything to do with the screen size issue. In fact, I think it's unrelated. I ran a test where no screen size escape sequence is emitted, and still see output 'freezing'. Maybe it's related to some sequence that vty is emitting.

Anyway, if we can figure these two problems out, I believe everything else works, and we can release support for mintty.
If you have some time, would you be able to take a look?

My work is checked in on the mintty-support branch.

[ShrykeWindgrace]

@chhackett that's quite a feat!

I do not think I will have much time for vty in the coming weeks, but I'll certainly take a look.

Uneducated guess with "\ESC[18t" and its output in the terminal - maybe it gets written to stderr or some other handle? This would explain both the inability to read and the presence on screen. That being said, I don't know whether stderr is readable at all =)

[ShrykeWindgrace]

@chhackett I finally got to work with your mintty support implementation.

First of all, it works almost out of the box=) It requires stty, and in my mobaXterm that was a stty.exe, had to make a symlink.

My tests were with vty-event-echo and vty-mode-demo from vty-crossplatform:

• on the app launch, the file "debug.log" is flooded with "getScreenSize..." and the app is indeed unresponsive.
• after a certain number of actions (pasting, maybe, or sufficient number of keypresses, I don't see a pattern) the TUI appears
• events are not handled immediately, it seems that they are handled by chunks of 4 (I press a key 5 times, and the app shows first four events)
• resizing the window clears the screen and then gets redrawn only after the 5th event (as above)

I tried launching my copies of mintty/git-bash from git-for-windows - it seems that it became intelligent enough to pick up the same backend as WindowsTerminal; apps built with released vty-crossplatform work out of the box (less work for us =) )

I'll try to run the interactive terminal test later.

[chhackett]

Ok, thanks for trying it out! I'll see if I can reproduce that event behavior this weekend sometime. I never noticed that pattern of only handling every 4th event.

Btw, the other thing we will need to figure out is how to detect whether the environment is cmd/powershell vs mintty. Right now, I just try calling the getConsoleMode - if it fails, then we must be in 'mintty' environment, otherwise regular cmd/powershell.

But that feels very unhaskelly. I tried using the mintty library which provides a function isMintty. But that always returned false for me even when it was running in mintty... If we could figure out the eventing issue, and that problem, we might be done.

[chhackett]

@ShrykeWindgrace
I found a different solution. It turns out, ghcup worked in MSYS2 terminals already without any changes. After investigating, I discovered that by using CONIN$ and CONOUT$ strings, we are able to configure the MSYS terminal for VT processing with no other changes required.
So I did that, and it seems to work great. Thanks for @hasufell for the solution.

[chhackett]

@ShrykeWindgrace @jdaugherty
Just a heads up that I've released version 2.0.3 which adds support for mintty terminals, and seems to function correctly with alacritty, and ConEmu as well. At this point, I think we have support for all the major terminals.