feature request: detect Windows Terminal

[Delta456]

Hey! I really like your library and I will be using it for my module for detecting 8 bit color support for Windows Console. As this module also supports Cygwin, can you also add detection for Windows Terminal as it is entirely different from Windows Console.

Thanks!

[mattn]

Probably, to check environment variable WT_SESSION exists can detect Windows Terminal. But not perfect way.

[Delta456]

Yes I know that way too

[mattn]

Currently, I have no best idea to do it.

[Delta456]

Let's keep it open until it is implemented.

[heaths]

Are you trying to detect Windows Terminal, or whether VT100 is supported? Talking with @DHowett - who works on Windows Terminal - in cli/cli#4106, to better detect or even enable VT100 support (or close to it) which even conhost.exe has supported for a while, you should actually call SetConsoleMode with ENABLE_VIRTUAL_TERMINAL_PROCESSING (0x4) and if it returns an error (non-zero) don't signal that you support VT100.

So maybe a platform-specific implementation of something like IsVTSupported() would do, though I don't know exactly what assumptions or detections you can make in the various other supported platforms.

[Delta456]

Yes, I now have to check that if VT100 is supported. As you say even CMD and Powershell can display 16 bit colors when you enable Virtual Terminal Processing. I have done the check in here but I still think that it will not always work.

[heaths]

16 color indexes were always supported. Enabling virtual processing enables 256color or truecolor depending on the terminal. Windows Terminal supports truecolor. There's also a quirk of the last column being used when VT processing is not enabled, which we're dealing with in cli/cli#4106.

[Delta456]

Oh I meant to write True Color 😅

[mattn]

FYI, go-colorable already support ENABLE_VIRTUAL_TERMINAL_PROCESSING.

https://github.com/mattn/go-colorable/blob/2e1b0c1546e0173c0907cf05c67b8ba29ed8b4d1/colorable_windows.go#L1026

[heaths]

I saw that, but it assumes coloring is enabled if it can't get or set the console mode. In the case we needed, that assumption would be false.

Besides, it's more than just coloring. In a library such as mattn/go-isatty that is is more of a general purpose TTY library, separate detection/enablement for VT100 support (or a close approximation for Windows, as @DHowett put it) would probably be best. If it is/can be enabled, at least 256color support can also be assumed. Unfortunately, it seems that truecolor support detection is a little trickier, but may only affect a very small number of customers on a small range of Windows 10 where, I believe, only the latest version of that range is supported but not for much longer (TH2, I believe).

[mattn]

Sorry, I still not understand what go-isatty can do. Adding new function like IsWindowsTerminal() bool ?

[heaths]

VT100 support is not just in Windows Terminal, but in conhost as of at least Windows 7 as well. I think just adding an IsVT100Supoorted() would suffice. I'm not sure what all the detect conditions for *nix are - perhaps just that "xterm" is defined in TERM or COLORTERM.

If VT100 is supported (at least in part - seems few, if any terminals, support it all), it's not just coloring that is possible, hence why it should be separate from mattn/go-colorable.

[mattn]

This is a code to check DRCS Sixel. UNIX terminal should send-back TerminalID for terminal report. At least, we can check support of VT100.

https://github.com/mattn/longcat/blob/62bfdec3ef9bebd028124cfee9f9d5e8d7eab938/main.go#L227

[mattn]

Could you please test this?

https://gist.github.com/mattn/00cf5b7e38f4cceaf7077f527479870c

[heaths]

Yes, it displayed a long cat in the following configurations:

• cmd.exe in conhost.exe
• powershell.exe in conhost.exe
• pwsh.exe in Windows Terminal
• bash in WSL2 in Windows Terminal
• cmd.exe in Windows Terminal