Feature Request: Clients of terminal need a way to inquire about the capabilities of the terminal

[rkeithhill]

Summary of the new feature/enhancement

Maybe this is as simple as an environment variable like VSCode uses for its terminal e.g. TERM_PROGRAM=WindowsTerminal / TERM_PROGRAM_VERSION=0.0.1.0.

Proposed technical implementation details (optional)

Start by creating the environment variables above so those of us using PowerShell can adapt our user experience (via PowerShell profiles) to Windows Terminal.

[DHowett-MSFT]

As of #897, you can look for $Env:WT_SESSION

[oising]

@DHowett-MSFT why not use TERM_PROGRAM also, like vs code, hyper and fluentterminal already do? Not too late to change :)

[vexx32]

Agreed. We can't keep creating new environment variables every single time a new terminal program comes out. Linux already uses $env:TERM and if we have to check several per platform it's just terrible from a UX standpoint. Why reinvent the wheel yet again?

[Jaykul]

An application-specific variable like WT_SESSION is really awful for anyone trying to determine what features they can use. I certainly don't want to have to check a dozen different environment variables to figure out what terminal I'm running in.

TERM_PROGRAM is slightly better, but is really just a lazy version of TERM, which is what all of these terminals should be setting.

Eventually, we're going to get a curses library and a real terminfo database with @TIC@ and @INFOCMP@ macros, shouldn't we start behaving well now?

[DHowett-MSFT]

Hold up, I think there's been a misunderstanding here. I'm sorry about that.

We should definitely support TERM or TERM_PROGRAM. Unfortunately, TERM has become somewhat like a user agent: "I work like this terminal, I promise" -- right up until it doesn't.
TERM_PROGRAM, I've never heard of. What does it do? Who is expected to use it, and for what?

WT_SESSION is something else. Today, it can be used to detect Windows Terminal. It is informative, not normative, as a detection mechanism. WT_SESSION tags an individual session -- it is a GUID that the shell (or some other enlightened application) can use in coordination with the terminal to support application state resumption. This feature was inspired by both Terminal.app (the stock terminal emulator on OS X) and its featureful replacement, iTerm2. There's no new and divergent art here.

The idea there is that if WT eventually supports reloading and showing a session's history, that resumed state will use the same session GUID so the shell can do additional things like restoring the working directory or anything else it might have saved off.

[DHowett-MSFT]

informative, not normative

This is why I threw it out as an example and didn't close the feature request. I'll seek to communicate things that are rattling around in my head a bit better going forward.

[heaths]

It would be nice if conhost would define new TERM values as well, so that we can know if we can use larger color palettes (of course, the fact it gets defined would imply that since it would be only in newer versions), differentiate conhost vs. Terminal, etc. In compiled code, it's easy enough to figure out via GetConsoleMode, but in shell scripts (cmd, powershell, etc.) not so much. For examples, flavors of linux define xterm, xterm-color, and xterm-256color, as well as many others. Some convention similar to that indicating color palette (level of VT support) or even Unicode support would be helpful to provide rich console experiences.