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

@DHowett-MSFT commented on GitHub (May 28, 2019):

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

@DHowett-MSFT commented on GitHub (May 28, 2019): As of #897, you can look for `$Env:WT_SESSION`

claunia commented

@oising commented on GitHub (May 28, 2019):

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

@oising commented on GitHub (May 28, 2019): @dhowett-msft why not use TERM_PROGRAM also, like vs code, hyper and fluentterminal already do? Not too late to change :)

claunia commented

@vexx32 commented on GitHub (May 28, 2019):

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?

@vexx32 commented on GitHub (May 28, 2019): 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?

claunia commented

@Jaykul commented on GitHub (May 28, 2019):

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?

@Jaykul commented on GitHub (May 28, 2019): 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](http://man7.org/linux/man-pages/man7/term.7.html), which is what all of these terminals **should** be setting. Eventually, we're _going_ to get a `curses` library and a real [terminfo](http://man7.org/linux/man-pages/man5/terminfo.5.html) database with `@TIC@` and `@INFOCMP@` macros, shouldn't we start behaving well now?

claunia commented

@DHowett-MSFT commented on GitHub (May 28, 2019):

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 commented on GitHub (May 28, 2019): 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.

claunia commented

@DHowett-MSFT commented on GitHub (May 28, 2019):

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.

@DHowett-MSFT commented on GitHub (May 28, 2019): > 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.

claunia commented

@heaths commented on GitHub (May 29, 2019):

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.

@heaths commented on GitHub (May 29, 2019): 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](https://github.com/microsoft/vswhere/blob/057095600d84844c353265295b3e9e3a26543a6d/src/vswhere.lib/Console.cpp#L14-L27) 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.

claunia commented

2026-01-30 22:24:41 +00:00

@be5invis commented on GitHub (Jul 4, 2019):

@DHowett-MSFT Maybe both? TERM_PROGRAM for the application name, and TERM for "feature detection"?

@be5invis commented on GitHub (Jul 4, 2019): @DHowett-MSFT Maybe both? `TERM_PROGRAM` for the application name, and `TERM` for "feature detection"?

claunia commented

@Tyriar commented on GitHub (Nov 25, 2019):

AFAIK the majority of (non-Windows?) terminals support TERM_PROGRAM and TERM_PROGRAM_VERSION, it's one of the few environment variables vscode's terminal touches (alongside TERM, LANG, COLORTERM). Whether WT should support TERM is another discussion.

TERM: Meant to encapsulate some of the capabilities of the terminal (alongside terminfo), it seems like a bit of a mess and pretty much everything sets this to xterm-256color for best compatibility (provided the terminal supports 256 color).
TERM_PROGRAM: Essentially the terminal's user agent, I think the primary use for this is to enable users to setup different profiles based on the terminal. For example under VS Code you may want a different terminal to a dedicated terminal like WT.
COLORTERM: An ugly extension to TERM to indicate support for true color sequences. Currently feels like a necessary evil to work with some apps that emit true color, I hope a better solution comes around eventually for this sort of feature detection.

@Tyriar commented on GitHub (Nov 25, 2019): AFAIK the majority of (non-Windows?) terminals support `TERM_PROGRAM` and `TERM_PROGRAM_VERSION`, it's one of the few environment variables vscode's terminal touches (alongside `TERM`, `LANG`, `COLORTERM`). Whether WT should support `TERM` is another discussion. - TERM: Meant to encapsulate some of the capabilities of the terminal (alongside terminfo), it seems like a bit of a mess and pretty much everything sets this to `xterm-256color` for best compatibility (provided the terminal supports 256 color). - TERM_PROGRAM: Essentially the terminal's user agent, I think the primary use for this is to enable users to setup different profiles based on the terminal. For example under VS Code you may want a different terminal to a dedicated terminal like WT. - COLORTERM: An ugly extension to TERM to indicate support for true color sequences. Currently feels like a necessary evil to work with some apps that emit true color, I hope a better solution comes around eventually for this sort of feature detection.

claunia commented

2026-01-30 22:24:41 +00:00

@bcdev-com commented on GitHub (Nov 28, 2019):

I just stumbled across an, obvious in retrospect, but irksome problem with using WT_SESSION as an indicator that you're running inside Windows Terminal. Since it is just a normal environment variable, it propagates as you'd expect, which means if you've launched VSCode from inside Windows Terminal, then the integrated terminal there also has WT_SESSION set, and to the parent value, which would stomp on the intended use for application state resumption.

That's behaving as expected, but certainly isn't desirable. Seems like more reason to need TERM_PROGRAM set as well.

@bcdev-com commented on GitHub (Nov 28, 2019): I just stumbled across an, obvious in retrospect, but irksome problem with using WT_SESSION as an indicator that you're running inside Windows Terminal. Since it is just a normal environment variable, it propagates as you'd expect, which means if you've launched VSCode from inside Windows Terminal, then the integrated terminal there also has WT_SESSION set, and to the parent value, which would stomp on the intended use for application state resumption. That's behaving as expected, but certainly isn't desirable. Seems like more reason to need TERM_PROGRAM set as well.

claunia commented

2026-01-30 22:24:41 +00:00

@DHowett-MSFT commented on GitHub (Nov 28, 2019):

Consider that TERM_PROGRAM would be inherited if you spawn another terminal emulator from WT- like, for example, :terminal in gvim. I’m not sure the heritability of environment variables makes the case for TERM_PROGRAM stronger exactly.

@DHowett-MSFT commented on GitHub (Nov 28, 2019): Consider that `TERM_PROGRAM` would be inherited if you spawn another terminal emulator from WT- like, for example, `:terminal` in gvim. I’m not sure the heritability of environment variables makes the case for `TERM_PROGRAM` _stronger_ exactly.

claunia commented

2026-01-30 22:24:42 +00:00

@bcdev-com commented on GitHub (Nov 28, 2019):

True, but if the defacto protocol is that all terminal emulators set TERM_PROGRAM (and presumably TERM_PROGRAM_VERSION) in the child environment that's a non-issue. That would make it a bug in gvim's :terminal support if it isn't overwriting those environment variables before spawning it's own shell process.

@bcdev-com commented on GitHub (Nov 28, 2019): True, but if the defacto protocol is that all terminal emulators set `TERM_PROGRAM` (and presumably `TERM_PROGRAM_VERSION`) in the child environment that's a non-issue. That would make it a bug in gvim's `:terminal` support if it isn't overwriting those environment variables before spawning it's own shell process.

claunia commented

2026-01-30 22:24:42 +00:00

@mixmastamyk commented on GitHub (Dec 13, 2019):

+1 vote for TERM_PROGRAM, it is also used on Apple and iTerm terminals.

Also, I just checked and WT_SESSION is set for CMD but not for WSL/bash. Whatever var y'all choose, it should be available from every shell for terminal detection to be reliable.

@mixmastamyk commented on GitHub (Dec 13, 2019): +1 vote for TERM_PROGRAM, it is also used on Apple and iTerm terminals. Also, I just checked and WT_SESSION is set for CMD but not for WSL/bash. Whatever var y'all choose, it should be available from every shell for terminal detection to be reliable.

claunia commented

2026-01-30 22:24:42 +00:00

@DHowett-MSFT commented on GitHub (Dec 13, 2019):

Thanks for that report; I split it out into #3948.

@DHowett-MSFT commented on GitHub (Dec 13, 2019): Thanks for that report; I split it out into #3948.

claunia commented

2026-01-30 22:24:43 +00:00

@gerardog commented on GitHub (Dec 17, 2019):

In my case I don't care much about what terminal program the end user is using, except that I want to know if I can send VT sequences or not. It would be nice if GetConsoleMode api returns the ENABLE_VIRTUAL_TERMINAL_PROCESSING flag enabled when called within a Windows Terminal console or other consoles that already supports VT. If it is possible for the Windows Terminal team implement this it may also be possible to request that on Cmder/ConEmu and have a standard windows way to determine that particular console capability. Using WT_SESSION environment variable already gave me a false positive because I am used to just use start cmd to spawn new consoles, and they inherit the env variable even when running on the regular ConHost.

@gerardog commented on GitHub (Dec 17, 2019): In my case I don't care much about what terminal program the end user is using, except that I want to know if I can send VT sequences or not. It would be nice if GetConsoleMode api returns the ENABLE_VIRTUAL_TERMINAL_PROCESSING flag enabled when called within a Windows Terminal console or other consoles that already supports VT. If it is possible for the Windows Terminal team implement this it may also be possible to request that on Cmder/ConEmu and have a standard windows way to determine that particular console capability. Using WT_SESSION environment variable already gave me a false positive because I am used to just use `start cmd` to spawn new consoles, and they inherit the env variable even when running on the regular ConHost.

claunia commented

2026-01-30 22:24:43 +00:00

@DHowett-MSFT commented on GitHub (Dec 17, 2019):

The presence of Windows Terminal, or any other terminal, does not indicate that the ENABLE_VIRTUAL_TERMINAL_PROCESSING flag is set. Because it is possible to store raw escape sequences in the text buffer with that flag turned off, it must be possible (and even, in some instances, recommended for legacy compatibility) to turn it off. Allowing the connected terminal to parse VT sequences that the console did not parse will lead to visual artifacting ala #1965 #2130 #2759 #1960.

@DHowett-MSFT commented on GitHub (Dec 17, 2019): The presence of Windows Terminal, or _any other terminal_, does _not_ indicate that the `ENABLE_VIRTUAL_TERMINAL_PROCESSING` flag is set. Because it is possible to store raw escape sequences in the text buffer with that flag turned off, it must be possible (and even, in some instances, recommended for legacy compatibility) to turn it off. Allowing the connected terminal to parse VT sequences that the console _did not parse_ will lead to visual artifacting ala #1965 #2130 #2759 #1960.

claunia commented

2026-01-30 22:24:44 +00:00

@Richienb commented on GitHub (Jan 15, 2020):

I propose the following spec:

As well as setting the WT_TERMINAL environmental variable, use a similar strategy to set TERM_PROGRAM to WindowsTerminal.

cc @DHowett-MSFT @heaths @Tyriar

Please get this out of the backlog.

@Richienb commented on GitHub (Jan 15, 2020): I propose the following spec: As well as setting the `WT_TERMINAL` environmental variable, use a similar strategy to set `TERM_PROGRAM` to `WindowsTerminal`. cc @DHowett-MSFT @heaths @Tyriar Please get this out of the backlog.

claunia commented

2026-01-30 22:24:44 +00:00

@DHowett-MSFT commented on GitHub (Jan 15, 2020):

Please get this out of the backlog.

I appreciate that there are folks who care about this, but I’m just not convinced of its value. TERM_PROGRAM has been likened to a browser user agent string, which makes good sense to me if you’re going to use a user agent string to do feature detection. By and large, the past 25 years of web development have shown us that that was almost certainly the wrong thing to do.

If somebody can come up with a legitimately compelling use case apart from “I want my shell to act differently if I’m in different terminals” (which is easily achievable through other means), I’m all ears!

Also: please don’t get in the habit of calling out contributors and community members by name when you want to be heard. If everyone did this for every one of our hundreds of open workitems that someone cares about, we would be deep in emails indeed. Most of us already are: we generally get an email for every comment on every bug in this repo.

@DHowett-MSFT commented on GitHub (Jan 15, 2020): > Please get this out of the backlog. I appreciate that there are folks who care about this, but I’m just not convinced of its value. `TERM_PROGRAM` has been likened to a browser user agent string, which makes good sense to me if you’re going to use a user agent string to do feature detection. By and large, the past 25 years of web development have shown us that _that was almost certainly the wrong thing to do_. If somebody can come up with a legitimately compelling use case apart from “I want my shell to act differently if I’m in different terminals” (which is easily achievable through other means), I’m all ears! Also: please don’t get in the habit of calling out contributors and community members by name when you want to be heard. If everyone did this for every one of our hundreds of open workitems that someone cares about, we would be deep in emails indeed. Most of us already are: we generally get an email for every comment on every bug in this repo.

claunia commented

2026-01-30 22:24:45 +00:00

@Richienb commented on GitHub (Jan 15, 2020):

@DHowett-MSFT

A big thing is compatibility detection. Especially for the new Emoji support.

If the script knows it's running in the Windows Terminal, it uses fancy emojis. If not, it uses legacy emojis pulled from Code page 437. At this point, using !!process.env.WT_SESSION to detect this just seems like a weird hack that isn't being used for its true purpose.

See https://github.com/sindresorhus/figures/pull/27#issuecomment-504764201

I need at least a thumbs up from a collaborator for this repository that WT_SESSION will be sticking around for a long time and that I can confidently rely on it.

@Richienb commented on GitHub (Jan 15, 2020): @DHowett-MSFT A big thing is compatibility detection. Especially for the new Emoji support. If the script knows it's running in the Windows Terminal, it uses fancy emojis. If not, it uses legacy emojis pulled from [Code page 437](https://en.wikipedia.org/wiki/Code_page_437). At this point, using `!!process.env.WT_SESSION` to detect this just seems like a weird hack that isn't being used for its true purpose. See https://github.com/sindresorhus/figures/pull/27#issuecomment-504764201 I need at least a thumbs up from a collaborator for this repository that `WT_SESSION` will be sticking around for a long time and that I can confidently rely on it.

claunia commented

2026-01-30 22:24:45 +00:00

@gerardog commented on GitHub (Jan 15, 2020):

Environment variables are not a perfect solution since you can 'start cmd' and that will open an old ConHost with WT_SESSION set.

@gerardog commented on GitHub (Jan 15, 2020): Environment variables are not a perfect solution since you can 'start cmd' and that will open an old ConHost with WT_SESSION set.

claunia commented

@Tyriar commented on GitHub (Jan 15, 2020):

@DHowett-MSFT for basically every other nix terminal and many on Windows, you can look at TERM_PROGRAM to see what terminal the app is being run within, but now anything that does this also needs to check WT_SESSION as well? And what if another terminal is launched from WT, then you have both TERM_PROGRAM and WT_SESSION so it's impossible to tell which value was set by the "inner" terminal (WT might create a fresh env block in which case this might not apply).

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.

You say it's inspired but why not do exactly what they did which is extend the TERM and TERM_PROGRAM variables with exactly what they did; adding TERM_SESSION_ID? imo you should replace WT_TERMINAL with TERM_SESSION_ID, add TERM_PROGRAM and TERM_PROGRAM_VERSION as there is already a standard and there is zero reason AFAICT to deviate from it.

@Tyriar commented on GitHub (Jan 15, 2020): @DHowett-MSFT for basically every other nix terminal and many on Windows, you can look at `TERM_PROGRAM` to see what terminal the app is being run within, but now anything that does this also needs to check `WT_SESSION` as well? And what if another terminal is launched from WT, then you have both `TERM_PROGRAM` and `WT_SESSION` so it's impossible to tell which value was set by the "inner" terminal (WT might create a fresh env block in which case this might not apply). > 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. You say it's inspired but why not do exactly what they did which is extend the `TERM` and `TERM_PROGRAM` variables with exactly what they did; adding `TERM_SESSION_ID`? imo you should replace `WT_TERMINAL` with `TERM_SESSION_ID`, add `TERM_PROGRAM` and `TERM_PROGRAM_VERSION` as there is already a standard and there is zero reason AFAICT to deviate from it.

claunia commented

@DHowett-MSFT commented on GitHub (Jan 15, 2020):

It is invalid to consider a terminal that does not set TERM_PROGRAM and TERM_PROGRAM_VERSION wrong. It stands, then, that any terminal started from another terminal that has set TERM_PROGRAM will inherit that value, and confuse all downstream shells.

There is no standard for session IDs: at my last check, Apple's Terminal.app used TERM_SESSION_ID and iTerm2.app uses ITERM_SESSION. Perhaps that has changed.

@DHowett-MSFT commented on GitHub (Jan 15, 2020): It is invalid to consider a terminal that does not set `TERM_PROGRAM` and `TERM_PROGRAM_VERSION` _wrong_. It stands, then, that any terminal started from another terminal that has set `TERM_PROGRAM` _will inherit that value, and confuse all downstream shells._ There is no standard for session IDs: at my last check, Apple's Terminal.app used `TERM_SESSION_ID` and iTerm2.app uses `ITERM_SESSION`. Perhaps that has changed.

claunia commented

@Tyriar commented on GitHub (Jan 15, 2020):

that any terminal started from another terminal that has set TERM_PROGRAM will inherit that value, and confuse all downstream shells.

The new terminal sets the value when it starts the process, so no confusion.

There is no standard for session IDs: at my last check, Apple's Terminal.app used TERM_SESSION_ID and iTerm2.app uses ITERM_SESSION. Perhaps that has changed.

Looks like iterm made a mistake and can't break backwards compat (iterm left, terminal.app right):

@Tyriar commented on GitHub (Jan 15, 2020): > that any terminal started from another terminal that has set TERM_PROGRAM will inherit that value, and confuse all downstream shells. The new terminal sets the value when it starts the process, so no confusion. >There is no standard for session IDs: at my last check, Apple's Terminal.app used TERM_SESSION_ID and iTerm2.app uses ITERM_SESSION. Perhaps that has changed. Looks like iterm made a mistake and can't break backwards compat (iterm left, terminal.app right): <img width="969" alt="Screen Shot 2020-01-15 at 12 03 10 PM" src="https://user-images.githubusercontent.com/2193314/72467055-04498700-378f-11ea-8da4-43d751ba7c45.png">

claunia commented

@Tyriar commented on GitHub (Jan 15, 2020):

Join us

@Tyriar commented on GitHub (Jan 15, 2020): Join us <img width="644" alt="Screen Shot 2020-01-15 at 12 12 52 PM" src="https://user-images.githubusercontent.com/2193314/72467717-65be2580-3790-11ea-84e0-5e2f9ab35009.png">

claunia commented

2026-01-30 22:24:47 +00:00

@gerardog commented on GitHub (Jan 15, 2020):

This should be set in both Windows Terminal and the windows built-in ConHost, to minimize the 'false positive' scenarios. I am pretty confident that other terminals will join too (Cmder/ConEmu,etc).

@gerardog commented on GitHub (Jan 15, 2020): This should be set in both Windows Terminal and the windows built-in ConHost, to minimize the 'false positive' scenarios. I am pretty confident that other terminals will join too (Cmder/ConEmu,etc).

claunia commented

@DHowett-MSFT commented on GitHub (Jan 15, 2020):

There's a problem with that one, too. conhost cannot set an environment variable in the process it's hosting, because it is actually spawned BY the process it is hosting.
That's just not a capability that's afforded to Windows applications. ConEmu supports two launch modes- one where it launches the shell and the conhost and attaches to the conhost, and one where it attaches to an existing conhost. It will not be able to set environment variables in the second case.

There's a lot more issues here than may initially meet the eye.

@DHowett-MSFT commented on GitHub (Jan 15, 2020): There's a problem with that one, too. conhost cannot set an environment variable in the process it's hosting, because _it is actually spawned BY the process it is hosting._ That's just not a capability that's afforded to Windows applications. ConEmu supports two launch modes- one where it launches the shell and the conhost and attaches to the conhost, and one where it attaches to an _existing_ conhost. It will not be able to set environment variables in the second case. There's a lot more issues here than may initially meet the eye.

claunia commented

2026-01-30 22:24:47 +00:00

@eryksun commented on GitHub (Jan 15, 2020):

There's a problem with that one, too. conhost cannot set an environment variable in the process it's hosting, because it is actually spawned BY the process it is hosting.

The Windows team could modify the allocate/attach code in kernelbase.dll to query the console host name and version and set those environment variables.

@eryksun commented on GitHub (Jan 15, 2020): > There's a problem with that one, too. conhost cannot set an environment variable in the process it's hosting, because _it is actually spawned BY the process it is hosting._ The Windows team could modify the allocate/attach code in kernelbase.dll to query the console host name and version and set those environment variables.

claunia commented

2026-01-30 22:24:47 +00:00

@garyo commented on GitHub (Jun 1, 2020):

So as a user, to get 24bit support in apps in WSL with Windows Terminal, is this the recommended method:

[[ -n "$WT_SESSION" ]] && export COLORTERM=24bit

at least for now?

@garyo commented on GitHub (Jun 1, 2020): So as a user, to get 24bit support in apps in WSL with Windows Terminal, is this the recommended method: ```sh [[ -n "$WT_SESSION" ]] && export COLORTERM=24bit ``` at least for now?

claunia commented

@DHowett commented on GitHub (Jun 1, 2020):

Definitely not. Client of Terminal will want to use the same means of detecting 24-bit color they were using for years before Windows Terminal came out. The traditional Windows console host has supported 24-bit color for some time now.

@DHowett commented on GitHub (Jun 1, 2020): Definitely not. Client of Terminal will want to use the same means of detecting 24-bit color they were using for years before Windows Terminal came out. The traditional Windows console host has supported 24-bit color for some time now.

claunia commented

@garyo commented on GitHub (Jun 1, 2020):

OK @DHowett -- what is the recommended method for a user then? I have a number of Linux utilities that assume that a 24bit terminal sets COLORTERM (they may have other methods I don't know about). They do not currently autodetect 24-bit support in Windows Terminal, even though it does support it. When I add COLORTERM=24bit they work OK. Is there some alternative method I should use?

@garyo commented on GitHub (Jun 1, 2020): OK @DHowett -- what is the recommended method for a user then? I have a number of Linux utilities that assume that a 24bit terminal sets `COLORTERM` (they may have other methods I don't know about). They do not currently autodetect 24-bit support in Windows Terminal, even though it does support it. When I add `COLORTERM=24bit` they work OK. Is there some alternative method I should use?

claunia commented

@DHowett commented on GitHub (Jun 1, 2020):

So, COLORTERM should be safe to set for all terminals on Windows as of 1803. No need to check WT_SESSION, just set it if you're using WSL at all. 😄

@DHowett commented on GitHub (Jun 1, 2020): So, `COLORTERM` should be safe to set for all terminals on Windows as of 1803. No need to check `WT_SESSION`, just set it if you're using WSL at all. :smile:

claunia commented

@garyo commented on GitHub (Jun 1, 2020):

I guess that's what I mean. I have a .bashrc which I use on Windows, Linux (incl WSL) and Mac. I want it to work everywhere. So I can either check that I'm on Windows (but then I still might be in Msys using some term emulator), or just check for WT_SESSION.
I do think it would be nice if Windows Terminal would just set COLORTERM like many other terminal apps (terminator, iTerm2, konsole, hyper, etc.).

@garyo commented on GitHub (Jun 1, 2020): I guess that's what I mean. I have a `.bashrc` which I use on Windows, Linux (incl WSL) and Mac. I want it to work everywhere. So I can either check that I'm on Windows (but then I still might be in Msys using some term emulator), or just check for `WT_SESSION`. I do think it would be nice if Windows Terminal would just set `COLORTERM` like many other terminal apps (terminator, iTerm2, konsole, hyper, etc.).

claunia commented

@DHowett commented on GitHub (Jun 1, 2020):

Fair request.

I would, though, hope that iTerm/Terminal.app and whatever terminal emulator you use on Linux would support 24-bit color by now. Perhaps if TERM == xterm-256color, you can set it?

@DHowett commented on GitHub (Jun 1, 2020): Fair request. I would, though, hope that iTerm/Terminal.app and whatever terminal emulator you use on Linux would support 24-bit color by now. Perhaps if `TERM` == `xterm-256color`, you can set it?

claunia commented

@heaths commented on GitHub (Jun 1, 2020):

Would it make more sense, then, to just have conhost and openconsole define TERM even if they are "xterm-256color" assuming ENABLE_VIRTUAL_TERMINAL_PROCESSING is enabled?

@heaths commented on GitHub (Jun 1, 2020): Would it make more sense, then, to just have conhost and openconsole define `TERM` even if they are "xterm-256color" assuming `ENABLE_VIRTUAL_TERMINAL_PROCESSING` is enabled?

claunia commented

@DHowett commented on GitHub (Jun 1, 2020):

WSL already does this.

@DHowett commented on GitHub (Jun 1, 2020): WSL already does this. ![image](https://user-images.githubusercontent.com/189190/83438604-8e208680-a3f6-11ea-86a4-6d603cac1347.png)

claunia commented

@garyo commented on GitHub (Jun 1, 2020):

Sure, that's reasonable. It's likely most terminal emulators claiming 256-color support actually support 24bit at this point.
There's a list at https://gist.github.com/XVilka/8346728 if anyone's interested.

@garyo commented on GitHub (Jun 1, 2020): Sure, that's reasonable. It's likely most terminal emulators claiming 256-color support actually support 24bit at this point. There's a list at https://gist.github.com/XVilka/8346728 if anyone's interested.

claunia commented

@heaths commented on GitHub (Jun 1, 2020):

WSL does, yes, but that doesn't help my many PowerShell scripts (cross-plat, or Windows-only) where emitting vterm sequences would be easier than chaining Write-Host with various -ForegroundColor or -BackgroundColor parameters.

@heaths commented on GitHub (Jun 1, 2020): WSL does, yes, but that doesn't help my many PowerShell scripts (cross-plat, or Windows-only) where emitting vterm sequences would be easier than chaining `Write-Host` with various `-ForegroundColor` or `-BackgroundColor` parameters.

claunia commented

@musm commented on GitHub (Jul 24, 2020):

Just chiming in that in my case, we have a program that probes COLORTERM and checks if it it's 24-bit or 256 to determine which color mode to enable.

I'm still confused/unclear on how to go about this for Windows users?

Should we just uniformly assume a 24-bit terminal if WT_SESSION is detected? (That doesn't seem right because 24-bit colors are supported by just launching cmd.exe directly so this test would fail for this case)

Or is it better to probe the console mode to confirm ENABLE_VIRTUAL_TERMINAL_PROCESSING is set (not ideal, extra code for this)

@musm commented on GitHub (Jul 24, 2020): Just chiming in that in my case, we have a program that probes `COLORTERM` and checks if it it's 24-bit or 256 to determine which color mode to enable. I'm still confused/unclear on how to go about this for Windows users? Should we just uniformly assume a 24-bit terminal if `WT_SESSION` is detected? (That doesn't seem right because 24-bit colors are supported by just launching cmd.exe directly so this test would fail for this case) Or is it better to probe the console mode to confirm ENABLE_VIRTUAL_TERMINAL_PROCESSING is set (not ideal, extra code for this)

claunia commented

@musm commented on GitHub (Jul 24, 2020):

Is it safe to emulate by setting TERM=xterm-256color if console mode has ENABLE_VIRTUAL_TERMINAL_PROCESSING set?

@musm commented on GitHub (Jul 24, 2020): Is it safe to emulate by setting `TERM=xterm-256color` if console mode has `ENABLE_VIRTUAL_TERMINAL_PROCESSING ` set?

claunia commented

@zadjii-msft commented on GitHub (Jul 31, 2020):

Is it safe to emulate by setting TERM=xterm-256color if console mode has ENABLE_VIRTUAL_TERMINAL_PROCESSING set?

That's certainly the TERM that we've been aiming to emulate, yea. If you can set ENABLE_VIRTUAL_TERMINAL_PROCESSING, then you should assume that the Console (and terminal) will be able to support 256/rgb colors. There's like, 1 build of Windows 10 (RS1, 14393 I think) where that won't work for you, but that was also just about 4 years ago, so I wouldn't worry about that too much.

@zadjii-msft commented on GitHub (Jul 31, 2020): > Is it safe to emulate by setting `TERM=xterm-256color` if console mode has `ENABLE_VIRTUAL_TERMINAL_PROCESSING ` set? That's certainly the `TERM` that we've been aiming to emulate, yea. If you can set `ENABLE_VIRTUAL_TERMINAL_PROCESSING`, then you should assume that the Console (and terminal) will be able to support 256/rgb colors. There's like, 1 build of Windows 10 (RS1, 14393 I think) where that won't work for you, but that was also just about 4 years ago, so I wouldn't worry about that too much.

claunia commented

@garyo commented on GitHub (Jul 31, 2020):

Would be great if there were a built-in env var or a way to do this query
without having to write a separate binary. Maybe Windows Terminal could
ship with this little utility?

@garyo commented on GitHub (Jul 31, 2020): Would be great if there were a built-in env var or a way to do this query without having to write a separate binary. Maybe Windows Terminal could ship with this little utility?

claunia commented

More details on color support

@tracker1 commented on GitHub (Aug 21, 2020):

@tracker1 commented on GitHub (Aug 21, 2020): [More details on color support](http://jdebp.eu/Softwares/nosh/guide/TerminalCapabilities.html#:~:text=Where%20the%20COLORTERM%20environment%20variable,8613%2D6%2FITU%20T.&text=The%20COLORTERM%20environment%20variable%20is,8613%2D6%2FITU%20T.)

claunia commented

@mixmastamyk commented on GitHub (Aug 27, 2020):

Just a note that I've recently discovered that the modern terminfo name for terminals that support direct, aka "true" color is TERM=xterm-direct not TERM=xterm-256color .

In fact a number of terminals have -direct aliases. To compare them:

⏵ infocmp xterm-256color xterm-direct

@mixmastamyk commented on GitHub (Aug 27, 2020): Just a note that I've recently discovered that the modern terminfo name for terminals that support direct, aka "true" color is `TERM=xterm-direct` not `TERM=xterm-256color` . In fact a number of terminals have `-direct` aliases. To compare them: ⏵ infocmp xterm-256color xterm-direct

claunia commented

@DHowett commented on GitHub (Aug 27, 2020):

Unfortunately, until we land #4321 we're actually +indirect 😦 (since we use the legacy syntax popularized by a misreading of the direct color spec!)

@DHowett commented on GitHub (Aug 27, 2020): Unfortunately, until we land #4321 we're actually `+indirect` 😦 (since we use the legacy syntax popularized by a misreading of the direct color spec!)

claunia commented

@mixmastamyk commented on GitHub (Aug 28, 2020):

Yes, got it. Since the comment was meant as more of a goal than a current status, it shouldn't be in conflict. Simply a note that, while in most threads folks are mentioning TERM=*-256color, those profiles have been surpassed for a number of years.

@mixmastamyk commented on GitHub (Aug 28, 2020): Yes, got it. Since the comment was meant as more of a goal than a current status, it shouldn't be in conflict. Simply a note that, while in most threads folks are mentioning `TERM=*-256color`, those profiles have been surpassed for a number of years.

claunia commented

@dropsonic commented on GitHub (Nov 24, 2020):

Please also make a PR to supports-hyperlinks that is intended to detect embedded hyperlinks support. Right now it is not possible to detect that Windows Terminal has v1.4 or higher so it is not possible to properly implement the terminal&version check.

@dropsonic commented on GitHub (Nov 24, 2020): Please also make a PR to [`supports-hyperlinks`](https://github.com/jamestalmage/supports-hyperlinks/issues/7) that is intended to detect embedded hyperlinks support. Right now it is not possible to detect that Windows Terminal has v1.4 or higher so it is not possible to properly implement the terminal&version check.

claunia commented

@Delta456 commented on GitHub (Nov 27, 2020):

It will be handy to have COLORTERM environment variable to detect true color support.

@Delta456 commented on GitHub (Nov 27, 2020): It will be handy to have `COLORTERM` environment variable to detect true color support.

claunia commented

@potatoqualitee commented on GitHub (Jan 8, 2021):

Excellent and useful additions, thank you so much.

@potatoqualitee commented on GitHub (Jan 8, 2021): Excellent and useful additions, thank you so much.

claunia commented

@heaths commented on GitHub (Jan 8, 2021):

@dropsonic why would detection be necessary? If vterm sequences are implemented correctly - and according to discussions for hyperlink support, Terminal is - if older Terminals don't support it hyperlinks will just show up as text (the URL, that is).

@heaths commented on GitHub (Jan 8, 2021): @dropsonic why would detection be necessary? If vterm sequences are implemented correctly - and according to discussions for hyperlink support, Terminal is - if older Terminals don't support it hyperlinks will just show up as text (the URL, that is).

claunia commented

@dropsonic commented on GitHub (Jan 10, 2021):

@heaths thanks for pointing it out, will try

@dropsonic commented on GitHub (Jan 10, 2021): @heaths thanks for pointing it out, will try

claunia commented

@WSLUser commented on GitHub (Jan 20, 2021):

@zadjii-msft Might Unibilium possibly be of help for this?

@WSLUser commented on GitHub (Jan 20, 2021): @zadjii-msft Might [Unibilium](https://github.com/neovim/unibilium) possibly be of help for this?

claunia commented

@DHowett commented on GitHub (Jan 20, 2021):

That license might make it a hard sell.

@DHowett commented on GitHub (Jan 20, 2021): That license might make it a hard sell.

claunia commented

@WSLUser commented on GitHub (Jan 20, 2021):

Perhaps a refactor that's Windows specific could be used with a new license (including switching to C++ from C). I filed an issue as well but I think it's not likely for them to change it. But who knows, it's a new year, maybe the neovim maintainers will be generous enough to remove that barrier.

@WSLUser commented on GitHub (Jan 20, 2021): Perhaps a refactor that's Windows specific could be used with a new license (including switching to C++ from C). I filed an issue as well but I think it's not likely for them to change it. But who knows, it's a new year, maybe the neovim maintainers will be generous enough to remove that barrier.

claunia commented

@zadjii-msft commented on GitHub (Jan 20, 2021):

That doesn't seem like it would be useful by itself. Couple thoughts:

I don't totally remember how GPL works, but I'm under the impression that if someone wanted a refactor to have a different license, it would have to not use any of the original code. In that case, is it even the same lib anymore?
I'd expect that this would still require OS-side work to support terminfos in Windows - which there is no support at all currently.

So I'm gonna say probably no.

@zadjii-msft commented on GitHub (Jan 20, 2021): That doesn't seem like it would be useful by itself. Couple thoughts: * I don't totally remember how GPL works, but I'm under the impression that if someone wanted a refactor to have a different license, it would have to _not use any of the original code_. In that case, _is it even the same lib anymore_? * I'd expect that this would still require OS-side work to support terminfos in Windows - which there is no support at all currently. So I'm gonna say probably _no_.

claunia commented

@tracker1 commented on GitHub (Feb 23, 2021):

@zadjii-msft The open modifications would only need to be part of the library itself as Lesser GPL (LGPL), and doesn't infect upstream projects. Not sure if/how it would work in terms of how Terminal is made. And I know MS is adverse, as we all are to GPL work, though LGPL is more reasonable.

@tracker1 commented on GitHub (Feb 23, 2021): @zadjii-msft The open modifications would only need to be part of the library itself as Lesser GPL (LGPL), and doesn't infect upstream projects. Not sure if/how it would work in terms of how Terminal is made. And I know MS is adverse, as we all are to GPL work, though LGPL is more reasonable.

claunia commented

@jamestalmage commented on GitHub (Apr 6, 2021):

@heaths Feature detection absolutely is necessary. supports-hyperlinks is a widely used module in the Node.js community for just that purpose. For formatted output (like tables) it's an absolute necessity. For output like that of this module (implementation here), the author is explicitly opting to just not show urls when hyperlinks aren't supported, because their added length would clobber the output. This comment explains the need further.

I'm not sure what portion of the 9 million weekly downloads of supports-hyperlinks are Windows Terminal users, but they're all currently missing out on hyperlinks even though they're supported by their terminal.

@jamestalmage commented on GitHub (Apr 6, 2021): @heaths Feature detection absolutely is necessary. `supports-hyperlinks` is a widely used module in the Node.js community for just that purpose. For formatted output (like tables) it's an absolute necessity. For output like that of [this module](https://github.com/sindresorhus/eslint-formatter-pretty) (implementation [here](https://github.com/sindresorhus/eslint-formatter-pretty/blob/main/index.js#L139)), the author is explicitly opting to just not show urls when hyperlinks aren't supported, because their added length would clobber the output. [This comment](https://github.com/jamestalmage/supports-hyperlinks/pull/8#issuecomment-814398184) explains the need further. I'm not sure what portion of the 9 million weekly downloads of [`supports-hyperlinks`](https://www.npmjs.com/package/supports-hyperlinks) are Windows Terminal users, but they're all currently missing out on hyperlinks even though they're supported by their terminal.

claunia commented

@tracker1 commented on GitHub (Apr 9, 2021):

I understand the aversion to avoid stuffing environment variables, and that proper capabilities detection is preferred, the old saying of, "Don't Let The Perfect Be The Enemy Of The Good" applies here.

TERM_PROGRAM and TERM_PROGRAM_VERSION are already widely used fields, and given how muddy TERM has been, where most terminals are simply xterm-256color or similar, trying to "fix" that will likely be more disruptive to existing applications. Terminals evolve, and as bad as it is, knowing the program itself and the version, and being able to do this in a consistent way are more important than trying to create a better solution.

Capabilities lookups may indeed lag here... and even then, there are often cases where a very specific point release of an application may have issues... Broken list api in IE 5.0.0, or broken JSON parser in IE 8.x for example. As developers we need to be able to work around these issues, and not knowing definitively the application and the version in a consistent way is just plain bad.

I know there is WT_SESSION okay, now we know the terminal in a completely different way than any other terminal in existence. And we still do emphatically NOT know the version. I cannot for the life of me figure out why this feature request is so controversial or why it has sat here for the better part of two years. This could easily have been a solved problem with those affected able to make their adjustments and move on by now.

Tagging: @DHowett-MSFT @zadjii-msft

@tracker1 commented on GitHub (Apr 9, 2021): I understand the aversion to avoid stuffing environment variables, and that proper capabilities detection is preferred, the old saying of, "Don't Let The Perfect Be The Enemy Of The Good" applies here. `TERM_PROGRAM` and `TERM_PROGRAM_VERSION` are already widely used fields, and given how muddy `TERM` has been, where most terminals are simply `xterm-256color` or similar, trying to "fix" that will likely be more disruptive to existing applications. Terminals evolve, and as bad as it is, knowing the program itself and the version, and being able to do this in a consistent way are more important than trying to create a better solution. Capabilities lookups may indeed lag here... and even then, there are often cases where a very specific point release of an application may have issues... Broken list api in IE 5.0.0, or broken JSON parser in IE 8.x for example. As developers we need to be able to work around these issues, and not knowing definitively the application and the version in a consistent way is just plain bad. I know there is `WT_SESSION` okay, now we know the terminal in a completely different way than any other terminal in existence. And we still do emphatically *NOT* know the version. I cannot for the life of me figure out why this feature request is so controversial or why it has sat here for the better part of two years. This could easily have been a solved problem with those affected able to make their adjustments and move on by now. Tagging: @DHowett-MSFT @zadjii-msft

claunia commented

@orta commented on GitHub (Jan 8, 2022):

In case you want more concrete examples of needing this, I'm midway through adding some hyperlinks in the output from the TypeScript compiler but can't reliably support Windows Terminal without being able to do a version check from inside the process (for other terminals I use TERM_PROGRAM_VERSION.) Given that the support is relatively new and there's probably a non-trivial number of older installs around, we'd end up giving them a bad experience.

@orta commented on GitHub (Jan 8, 2022): In case you want more concrete examples of needing this, I'm midway through adding some hyperlinks in the output from the TypeScript compiler but can't reliably support Windows Terminal without being able to do a version check from inside the process (for other terminals I use `TERM_PROGRAM_VERSION`.) Given that the support is relatively new and there's probably a non-trivial number of older installs around, we'd end up giving them a bad experience.

claunia commented

@heaths commented on GitHub (Jan 10, 2022):

@orta depending on how you're linking, you may not need to check. See my comment above. That may not work in all cases, though; and, don't get me wrong, I 💯 agree we need some way of checking TERM support, though I understand from this thread there's no good standard to implement. Cue xkcd's comic on inventing a new standard!

@heaths commented on GitHub (Jan 10, 2022): @orta depending on how you're linking, you may not need to check. See my [comment above](https://github.com/microsoft/terminal/issues/1040#issuecomment-756953154). That may not work in all cases, though; and, don't get me wrong, I 💯 agree we need some way of checking TERM support, though I understand from this thread there's no good standard to implement. Cue xkcd's comic on inventing a new standard!

claunia commented

@axelfontaine commented on GitHub (Feb 17, 2022):

WT_SESSION also doesn't work reliably in Win11 x64 with Windows Terminal set as default.

To reproduce, press the Windows key to open start, then type cmd + enter

This now opens a Windows Terminal cmd.exe tab via %USER_PROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\System Tools\Command Prompt.lnk where WT_SESSION is not set.

@axelfontaine commented on GitHub (Feb 17, 2022): `WT_SESSION` also doesn't work reliably in Win11 x64 with Windows Terminal set as default. To reproduce, press the Windows key to open start, then type `cmd` + enter This now opens a Windows Terminal cmd.exe tab via `%USER_PROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\System Tools\Command Prompt.lnk` where `WT_SESSION` is not set.

claunia commented

@zadjii-msft commented on GitHub (Feb 17, 2022):

WT_SESSION also doesn't work reliably in Win11 x64 with Windows Terminal set as default.

This is a great example of why I wasn't in love with the env var solution in the first place. It's never going to be totally reliable.

The defterm scenario is never going to work with WT_SESSION. When the Terminal is invoked for a defterm connection, cmd.exe is already running. At this point, it's environment variables are already set. It's started, so there's nothing WT can do to change them now. Then, the OS tries to create a console to host the cmd process. conhost does some work, and hooks up the cmd.exe to the Terminal (or some other terminal!). The Terminal can only add the WT_SESSION variable when WT is the parent, launching cmd.exe directly.

@zadjii-msft commented on GitHub (Feb 17, 2022): > `WT_SESSION` also doesn't work reliably in Win11 x64 with Windows Terminal set as default. This is a great example of why I wasn't in love with the env var solution in the first place. It's never going to be totally reliable. The defterm scenario is _never_ going to work with `WT_SESSION`. When the Terminal is invoked for a defterm connection, `cmd.exe` is already running. At this point, it's environment variables are already set. It's started, so there's nothing WT can do to change them now. Then, the OS tries to create a console to host the `cmd` process. `conhost` does some work, and hooks up the `cmd.exe` to the Terminal (or some other terminal!). The Terminal can only add the `WT_SESSION` variable when WT is the parent, launching `cmd.exe` directly.

claunia commented

@garyo commented on GitHub (Feb 17, 2022):

This is a great example of why I wasn't in love with the env var solution in the first place. It's never going to be totally reliable.

OK, so env vars won't work in all cases. Is there another option? Perhaps Windows Terminal could ship with a small exe that, when run, checks how it's being run (parent processes, process groups, or some other OS method) and returns on stdout a JSON list of capabilities, version number, etc.? Just trying to be creative here.

@garyo commented on GitHub (Feb 17, 2022): > This is a great example of why I wasn't in love with the env var solution in the first place. It's never going to be totally reliable. OK, so env vars won't work in all cases. Is there another option? Perhaps Windows Terminal could ship with a small exe that, when run, checks how it's being run (parent processes, process groups, or some other OS method) and returns on stdout a JSON list of capabilities, version number, etc.? Just trying to be creative here.

claunia commented

@j4james commented on GitHub (Feb 17, 2022):

Exactly which capabilities do you need to detect? There should already be standard escape sequences for detecting most features that apps might be interested in. We don't support all of those sequences yet, but that's something I'm hoping to get to eventually.

@j4james commented on GitHub (Feb 17, 2022): Exactly which capabilities do you need to detect? There should already be standard escape sequences for detecting most features that apps might be interested in. We don't support all of those sequences yet, but that's something I'm hoping to get to eventually.

claunia commented

@axelfontaine commented on GitHub (Feb 17, 2022):

@j4james ANSI escape code and emoji rendering support.

@axelfontaine commented on GitHub (Feb 17, 2022): @j4james ANSI escape code and emoji rendering support.

claunia commented

@Jaykul commented on GitHub (Feb 17, 2022):

This is a great example of why I wasn't in love with the env var solution in the first place. It's never going to be totally reliable.

OK, so env vars won't work in all cases. Is there another option? Perhaps Windows Terminal could ship with a small exe that, when run, checks how it's being run (parent processes, process groups, or some other OS method) and returns on stdout a JSON list of capabilities, version number, etc.? Just trying to be creative here.

The thing is, it does: wt --version is a thing, but it pops up a GUI 🤣

@Jaykul commented on GitHub (Feb 17, 2022): > > This is a great example of why I wasn't in love with the env var solution in the first place. It's never going to be totally reliable. > > OK, so env vars won't work in all cases. Is there another option? Perhaps Windows Terminal could ship with a small exe that, when run, checks how it's being run (parent processes, process groups, or some other OS method) and returns on stdout a JSON list of capabilities, version number, etc.? Just trying to be creative here. The thing is, it does: `wt --version` is a thing, but it pops up a GUI 🤣

claunia commented

@j4james commented on GitHub (Feb 17, 2022):

@axelfontaine ANSI escape codes you can detect by sending something like a CPR query and see if you get a response. Trying to detect "emoji rendering" is probably a lost cause.

@Jaykul I'm not sure how you'd expect that to help you anyway. Determining the version number of wt on the host machine tells you nothing about the capabilities of the client terminal.

@j4james commented on GitHub (Feb 17, 2022): @axelfontaine ANSI escape codes you can detect by sending something like a CPR query and see if you get a response. Trying to detect "emoji rendering" is probably a lost cause. @Jaykul I'm not sure how you'd expect that to help you anyway. Determining the version number of wt on the host machine tells you nothing about the capabilities of the client terminal.

claunia commented

@axelfontaine commented on GitHub (Feb 17, 2022):

@j4james "Running under WT?" is a good enough emoji rendering support detection algorithm as far as I'm concerned.

@axelfontaine commented on GitHub (Feb 17, 2022): @j4james "Running under WT?" is a good enough emoji rendering support detection algorithm as far as I'm concerned.

claunia commented

@zadjii-msft commented on GitHub (Feb 17, 2022):

maybe your algorithm should be return true 😝

(admittedly, I saved the file as UTF-8 then tried printing it to CP437 the first time, so that's on me)

@zadjii-msft commented on GitHub (Feb 17, 2022): ![emoji-work-in-conhost](https://user-images.githubusercontent.com/18356694/154521492-4927ea5d-6565-4d20-a3cc-dfc5db6b9f0b.gif) maybe your algorithm should be `return true` 😝 (admittedly, I saved the file as UTF-8 then tried printing it to CP437 the first time, so that's on me)

claunia commented

@DHowett commented on GitHub (Feb 17, 2022):

@j4james "Running under WT?" is a good enough emoji rendering support detection algorithm as far as I'm concerned.

maybe your algorithm should be return true 😝

Yup, this is an excellent example of a principle I've been talking about across this repository! In the fullness of time, "Are we running under WT?" will give you an incomplete and incorrect answer as to whether various things are supported on Windows. There are already folks in the wild who detect WT_SESSION and use that to determine whether to emit direct RGB color, for example... when the console has supported those colors since 2018. Discoverability is hard, but the simple fact remains that the things we do for the Terminal ultimately help the console that ships inside Windows as well. 😄

(Specifically, emoji rendering works thanks to alabuzhev working on the GDI engine; we would not have gotten to it without his help.)

@DHowett commented on GitHub (Feb 17, 2022): > @j4james "Running under WT?" is a good enough emoji rendering support detection algorithm as far as I'm concerned. > maybe your algorithm should be `return true` 😝 Yup, this is an excellent example of a principle I've been talking about across this repository! In the fullness of time, "Are we running under WT?" will give you an incomplete and incorrect answer as to whether various things are supported on Windows. There are _already_ folks in the wild who detect `WT_SESSION` and use that to determine whether to emit direct RGB color, for example... when the console has supported those colors since 2018. Discoverability is _hard_, but the simple fact remains that the things we do for the Terminal ultimately help the console that ships inside Windows as well. :smile: (Specifically, emoji rendering works thanks to alabuzhev working on the GDI engine; we would not have gotten to it without his help.)

claunia commented

@axelfontaine commented on GitHub (Feb 17, 2022):

@zadjii-msft I am well aware a .cmd file is still required to set chcp 65001 before launching my app. After that I currently detect whether WT_SESSION is 36 chars long. If that fails, then it's fallback to no-emoji no-ansi rendering. My comment was primarily about decreasing the number of false negatives to offer the improved experience to as many users as possible.

@axelfontaine commented on GitHub (Feb 17, 2022): @zadjii-msft I am well aware a `.cmd` file is still required to set `chcp 65001` before launching my app. After that I currently detect whether `WT_SESSION` is 36 chars long. If that fails, then it's fallback to no-emoji no-ansi rendering. My comment was primarily about decreasing the number of false negatives to offer the improved experience to as many users as possible.

claunia commented

@zadjii-msft commented on GitHub (Feb 17, 2022):

Sorry, I wasn't clear. The Window in my gif is conhost, not the Terminal. There's no WT_SESSION there, because it is not the Terminal. That's just the console. Emoji can work in the console as well as the terminal. That's part of the whole design of the Terminal - a most of the improvements we make to the Terminal's buffer and internals are things that the console can benefit from as well.

@zadjii-msft commented on GitHub (Feb 17, 2022): Sorry, I wasn't clear. The Window in my gif is _conhost_, not the Terminal. There's no `WT_SESSION` there, because _it is not the Terminal_. That's just the console. Emoji can work in the console as well as the terminal. That's part of the whole design of the Terminal - a most of the improvements we make to the Terminal's buffer and internals are things that the console can benefit from as well.

claunia commented

@heaths commented on GitHub (Feb 17, 2022):

OK, so env vars won't work in all cases. Is there another option?

Is a perfect solution necessary? It's clear from the thread that there's not really an established pattern, but TERM and COLORTERM come close. Close enough? For most indented purposes, seems "yes".

Running some EXE as suggested above or relying on Windows- or Windows Terminal-specific solutions don't make scripts portable, or at least make them harder to write (would always need a precondition of WT_SESSION which, as @zadjii-msft points out above, also isn't accurate).

Seems the sooner a solution is added that is close to what most other terminals do, the less workarounds get invented that might be even worse.

@heaths commented on GitHub (Feb 17, 2022): > OK, so env vars won't work in all cases. Is there another option? Is a perfect solution necessary? It's clear from the thread that there's not really an established pattern, but `TERM` and `COLORTERM` come close. Close enough? For most indented purposes, seems "yes". Running some EXE as suggested above or relying on Windows- or Windows Terminal-specific solutions don't make scripts portable, or at least make them harder to write (would always need a precondition of `WT_SESSION` which, as @zadjii-msft points out above, also isn't accurate). Seems the sooner a solution is added that is close to what most other terminals do, the less workarounds get invented that might be even worse.

claunia commented

https://gist.github.com/XVilka/8346728#querying-the-terminal

@j4james commented on GitHub (Feb 17, 2022):

@heaths If you're just trying to detect true color support, you should be able to use the standard method documented here:

I believe that should be supported in Windows Terminal from version 1.12.

@j4james commented on GitHub (Feb 17, 2022): @heaths If you're just trying to detect true color support, you should be able to use the standard method documented here: https://gist.github.com/XVilka/8346728#querying-the-terminal I believe that should be supported in Windows Terminal from version 1.12.

claunia commented

@heaths commented on GitHub (Feb 18, 2022):

My original reason for jumping onto this thread was to find an easy way a script or program can query. Even the suggested gist - which I had found previously - doesn't always work. Even if you replace : with ; in Windows Terminal, the response you get back isn't the same:

echo -e '\e[48;2;1;2;3m\eP$qm\e\\'
^[P1$r0;48;2;1;2;3m^[\

The gist shows "r;48" instead of what Windows Terminal reports back, "r0;48". So depending on what people are checking for when reading back, it seems to vary from terminal to terminal. Whether you use : or ; certainly does. For example, using : in WT gives back ^[P1$r0m^[\, which indicates WT doesn't support truecolor.

This makes it more difficult to write portable shell scripts as well, where an env var is pretty straight forward to use.

@heaths commented on GitHub (Feb 18, 2022): My original reason for jumping onto this thread was to find an easy way a script or program can query. Even the suggested gist - which I had found previously - doesn't always work. Even if you replace `:` with `;` in Windows Terminal, the response you get back isn't the same: ```bash echo -e '\e[48;2;1;2;3m\eP$qm\e\\' ^[P1$r0;48;2;1;2;3m^[\ ``` The gist shows "r;48" instead of what Windows Terminal reports back, "r0;48". So depending on what people are checking for when reading back, it seems to vary from terminal to terminal. Whether you use `:` or `;` certainly does. For example, using `:` in WT gives back `^[P1$r0m^[\`, which indicates WT doesn't support truecolor. This makes it more difficult to write portable shell scripts as well, where an env var is pretty straight forward to use.

claunia commented

@eryksun commented on GitHub (Feb 18, 2022):

The defterm scenario is never going to work with WT_SESSION. When the Terminal is invoked for a defterm connection, cmd.exe is already running. At this point, it's environment variables are already set. It's started, so there's nothing WT can do to change them now. Then, the OS tries to create a console to host the cmd process. conhost does some work, and hooks up the cmd.exe to the Terminal (or some other terminal!). The Terminal can only add the WT_SESSION variable when WT is the parent, launching cmd.exe directly.

When a console is allocated on the client side, the internal function ConsoleCreateConnectionObject() calls NtCreateFile() to open the connection to conhost. The connection request triggers the handoff in conhost. After connecting, the client side could call NtDeviceIoControlFile() with an IOCTL that requests session environment variables that need to be set (e.g. "TERM", "WT_SESSION", "WT_PROFILE_ID", "WSLENV"). The base API could also make this IOCTL when the console connection is inherited, or when attaching via AttachConsole(). This would ensure that clients always start with relevant session environment variables. The ConPTY API would include functions to get and set these session environment variables in the console server.

For handoff, the delegated console (openconsole) would need to obtain the session environment variables from the delegated terminal when it calls handoff->EstablishPtyHandoff(...), which could be either from an out parameter or a subsequent COM call. This guarantees their availability when the base API requests them.

@eryksun commented on GitHub (Feb 18, 2022): > The defterm scenario is _never_ going to work with `WT_SESSION`. When the Terminal is invoked for a defterm connection, `cmd.exe` is already running. At this point, it's environment variables are already set. It's started, so there's nothing WT can do to change them now. Then, the OS tries to create a console to host the `cmd` process. `conhost` does some work, and hooks up the `cmd.exe` to the Terminal (or some other terminal!). The Terminal can only add the `WT_SESSION` variable when WT is the parent, launching `cmd.exe` directly. When a console is allocated on the client side, the internal function `ConsoleCreateConnectionObject()` calls `NtCreateFile()` to open the connection to conhost. The connection request triggers the handoff in conhost. After connecting, the client side could call `NtDeviceIoControlFile()` with an IOCTL that requests session environment variables that need to be set (e.g. "TERM", "WT_SESSION", "WT_PROFILE_ID", "WSLENV"). The base API could also make this IOCTL when the console connection is inherited, or when attaching via `AttachConsole()`. This would ensure that clients always start with relevant session environment variables. The ConPTY API would include functions to get and set these session environment variables in the console server. For handoff, the delegated console (openconsole) would need to obtain the session environment variables from the delegated terminal when it calls `handoff->EstablishPtyHandoff(...)`, which could be either from an out parameter or a subsequent COM call. This guarantees their availability when the base API requests them.

claunia commented

@DHowett commented on GitHub (Feb 18, 2022):

I actually really like this. We've been thinking about what it would mean to extend the Console API surface, too, with both inbox consumers (conclnt) and out-of-box ones. The Windows release cycle gives us a bit of trouble, but since DefTerm is locked behind Windows updates as well ... it isn't as much of a problem. Interesting.

@DHowett commented on GitHub (Feb 18, 2022): I actually really like this. We've been thinking about what it would mean to extend the Console API surface, too, with both inbox consumers (conclnt) and out-of-box ones. The Windows release cycle gives us a bit of trouble, but since DefTerm is locked behind Windows updates as well ... it isn't as much of a problem. _Interesting._

claunia commented

@Jaykul commented on GitHub (Feb 18, 2022):

@heaths wrote:

echo -e '\e[48;2;1;2;3m\eP$qm\e\\'
^[P1$r0;48;2;1;2;3m^[\
The gist shows "r;48" instead of what Windows Terminal reports back, "r0;48".

The leading 0; is the SGR reset which "returns all attributes to the default state prior to modification".

The response for DCS $ q Pt ST according to ctlseqs is supposed to be: DCS 1 $ r Pt ST

When the query Pt is m you're going to get the SGR back as the Pt. Windows Terminal is returning: 0;48;2;1;2;3m which is the reset plus the background. Some other terminals may leave off the reset. For our purposes, you can (should) ignore it. You set the default background (48), so what you're trying to read is the value of 48.

I wrote Test-RgbMode for example, but I don't have a wide test base to verify it works.

@Jaykul commented on GitHub (Feb 18, 2022): @heaths wrote: > ```shell > echo -e '\e[48;2;1;2;3m\eP$qm\e\\' > ^[P1$r0;48;2;1;2;3m^[\ > ``` > The gist shows "r;48" instead of what Windows Terminal reports back, "r0;48". The leading `0;` is the SGR reset which "returns all attributes to the default state prior to modification". The response for `DCS $ q Pt ST` according to [ctlseqs](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html) is supposed to be: `DCS 1 $ r Pt ST` When the query `Pt` is `m` you're going to get the SGR back as the `Pt`. Windows Terminal is returning: `0;48;2;1;2;3m` which is the reset plus the background. Some other terminals may leave off the reset. For our purposes, you can (should) ignore it. You **set** the default background (48), so what you're trying to read is the value of 48. I wrote [Test-RgbMode](https://gist.github.com/Jaykul/f9aac8753b5fe39fa24a96bf7f4dc6b7#file-test-rgbmode-ps1) for example, but I don't have a wide test base to verify it works.

claunia commented

@heaths commented on GitHub (Feb 18, 2022):

Thanks for the explaining the 0 there. In hindsight I probably should've realized that (I tend to reset colors to be sure myself), but wasn't entirely sure what the printed sequence was representing.

But looking at your gist shows the complexity that any script would have to do in Windows Terminal as opposed to most other terminals with a combination of TERM and COLORTERM. Given the acquisition model for Windows Terminal (most people probably get it through the Windows Store) and update push model, is there any big downside of assuming the vast majority of customers have the latest and TERM and COLORTERM are enough? My concern is more about portability of scripts with common terminals and less about 100% accuracy. Wouldn't you agree that the vast majority of devs wanting to detect capabilities are probably most interested in terminal colors? Sure there's some one-offs for detecting if hyperlinks are supported, etc., but given that most customers would have the latest WT simply checking TERM for, say, "xterm-256color" or whatever it would be set to should be approximate.

Even the detection mechanism you demo above has variants for terminals like using : instead of ; so the logic becomes even more complicated. It's all possible, of course, but you start turning otherwise small shell scripts into much larger ones.

@heaths commented on GitHub (Feb 18, 2022): Thanks for the explaining the 0 there. In hindsight I probably should've realized that (I tend to reset colors to be sure myself), but wasn't entirely sure what the printed sequence was representing. But looking at your gist shows the complexity that any script would have to do in Windows Terminal as opposed to most other terminals with a combination of `TERM` and `COLORTERM`. Given the acquisition model for Windows Terminal (most people probably get it through the Windows Store) and update push model, is there any big downside of assuming the vast majority of customers have the latest and `TERM` and `COLORTERM` are enough? My concern is more about portability of scripts with common terminals and less about 100% accuracy. Wouldn't you agree that the vast majority of devs wanting to detect capabilities are probably most interested in terminal colors? Sure there's some one-offs for detecting if hyperlinks are supported, etc., but given that most customers would have the latest WT simply checking `TERM` for, say, "xterm-256color" or whatever it would be set to should be approximate. Even the detection mechanism you demo above has variants for terminals like using `:` instead of `;` so the logic becomes even more complicated. It's all possible, of course, but you start turning otherwise small shell scripts into much larger ones.

claunia commented

@j4james commented on GitHub (Feb 18, 2022):

@heaths Note that there are three different truecolor formats, and terminals don't necessarily support all of them. If COLORTERM is set to truecolor or 24bit, that indicates that the terminal might support some form of truecolor, but it doesn't tell you which formats will work. It's probably reasonable to assume the semicolon format, but that's not guaranteed.

For example, using : in WT gives back ^[P1$r0m^[\, which indicates WT doesn't support truecolor.

No - that's indicating that WT doesn't support the colon format, which is exactly the point. A COLORTERM variable wouldn't tell you that.

That said, if you're happy with the all the limitations of environment variables, that's fine. I just want to make sure you are actually aware of those limitations.

@j4james commented on GitHub (Feb 18, 2022): @heaths Note that there are three different truecolor formats, and terminals don't necessarily support all of them. If `COLORTERM` is set to _truecolor_ or _24bit_, that indicates that the terminal might support some form of truecolor, but it doesn't tell you which formats will work. It's probably reasonable to assume the semicolon format, but that's not guaranteed. > For example, using `:` in WT gives back `^[P1$r0m^[\`, which indicates WT doesn't support truecolor. No - that's indicating that WT doesn't support the colon format, which is exactly the point. A `COLORTERM` variable wouldn't tell you that. That said, if you're happy with the all the limitations of environment variables, that's fine. I just want to make sure you are actually aware of those limitations.

claunia commented

@heaths commented on GitHub (Feb 18, 2022):

I appreciate the limitations, yes. Not only have I been following this thread, but working with @DHowett offline with some GitHub CLI (and related modules) issues, along with a couple GitHub developers. The main reason I brought up my concern/question above was questioning whether or not the limitations of env vars like TERM and COLORTERM are worth it for the vast majority of cases. I posit: probably not. In scenarios where those limitations may be problematic, certainly app/script devs can query caps from the terminal as you've suggested - dealing with all the portability issues across shells.

Scenarios where env vars are probably good enough would be colors, I would think. Let's say that you only set TERM=xterm-256color and some shell decides to use 256 indexed colors instead of truecolor even though they could. Is that detrimental? Or if they merely check TERM for "xterm" to assume it supports OSC 8 (hyperlinks), WT would as long as they have a fairly recent (1.10?) version, which given Windows Store's (eventual) push model for updates is likely, especially as more time passes.

IMO, I just don't see a great reason to avoid using common TERM and COLORTERM even if they aren't 100% correct. For simple scenarios they should be good enough, as they have been even before Windows Terminal despite some differences across various terminals. When it matters, devs should be encouraged to query caps on the terminal. Both can be offered.

@heaths commented on GitHub (Feb 18, 2022): I appreciate the limitations, yes. Not only have I been following this thread, but working with @DHowett offline with some GitHub CLI (and related modules) issues, along with a couple GitHub developers. The main reason I brought up my [concern/question above](https://github.com/microsoft/terminal/issues/1040#issuecomment-1043620108) was questioning whether or not the limitations of env vars like `TERM` and `COLORTERM` are worth it for the vast majority of cases. I posit: probably not. In scenarios where those limitations may be problematic, certainly app/script devs can query caps from the terminal as you've suggested - dealing with all the portability issues across shells. Scenarios where env vars are probably good enough would be colors, I would think. Let's say that you only set `TERM=xterm-256color` and some shell decides to use 256 indexed colors instead of truecolor even though they could. Is that detrimental? Or if they merely check `TERM` for "xterm" to assume it supports OSC 8 (hyperlinks), WT would as long as they have a fairly recent (1.10?) version, which given Windows Store's (eventual) push model for updates is likely, especially as more time passes. IMO, I just don't see a great reason to avoid using common `TERM` and `COLORTERM` even if they aren't 100% correct. For simple scenarios they should be good enough, as they have been even before Windows Terminal despite some differences across various terminals. When it matters, devs should be encouraged to query caps on the terminal. Both can be offered.

claunia commented

@tracker1 commented on GitHub (Mar 9, 2022):

@j4james "Running under WT?" is a good enough emoji rendering support detection algorithm as far as I'm concerned.

Not for people actually making terminal programs that won't always be run in windows... not to mention there are different terminals for windows itself. WT_* may indicate that it's "Windows Terminal" that said it's a horrible experience when trying to support different terminals, or possibly even trying to create something that can detect features.

It's very similar to at least being able to get the application name (TERM_PROGRAM) and the version (TERM_PROGRAM_VERSION) so that you can handle, work around or determine specific implementation bugs, in a consistent way with other environments.

Specific, similar example.... Internet Explorer 5.0.0 had a very specific bug in which it implemented a new interface for managing the options in a <select> element that was fixed in 5.0.1 ... but at the time, it was written to every Windows 2000 and Office 2000 cd... that's an example of a very specific work around... that said, it happens more often than most would like to think.

In this case, the terminal is effectively a browser for a command line application, including the shell environment.

Some features that concern me that would be nice to be able to determine in a consistent way....

Color support, 16, 256, rgb including either/both delimiter options
UTF-8 or not, can we find out what the character set is otherwise?
Emojii (none, single color glyph, or color emojii)
Image rendering support/options
hyperlinks
Regions?
screen size
screen resize

Doing so in the most consistent way, termcap library support for WT, etc. But short of having at LEAST the TERM_PROGRAM, it's not at all consistent with other terminals.

For that matter, maybe a settings option for adding/setting/overriding custom environment variables, so the user can CHOOSE to add appropriate options for their environment (wsl, ssh, etc).

@tracker1 commented on GitHub (Mar 9, 2022): > @j4james "Running under WT?" is a good enough emoji rendering support detection algorithm as far as I'm concerned. Not for people actually making terminal programs that won't always be run in windows... not to mention there are different terminals for windows itself. WT_* may indicate that it's "Windows Terminal" that said it's a horrible experience when trying to support different terminals, or possibly even trying to create something that can detect features. It's very similar to *at least* being able to get the application name (`TERM_PROGRAM`) and the version (`TERM_PROGRAM_VERSION`) so that you can handle, work around or determine specific implementation bugs, in a consistent way with other environments. Specific, similar example.... Internet Explorer 5.0.0 had a very specific bug in which it implemented a new interface for managing the options in a `<select>` element that was fixed in 5.0.1 ... but at the time, it was written to every Windows 2000 and Office 2000 cd... that's an example of a very specific work around... that said, it happens more often than most would like to think. In this case, the terminal is effectively a browser for a command line application, including the shell environment. Some features that concern me that would be nice to be able to determine in a consistent way.... - Color support, 16, 256, rgb including either/both delimiter options - UTF-8 or not, can we find out what the character set is otherwise? - Emojii (none, single color glyph, or color emojii) - Image rendering support/options - hyperlinks - Regions? - screen size - screen resize Doing so in the most consistent way, termcap library support for WT, etc. But short of having at *LEAST* the TERM_PROGRAM, it's not at all consistent with other terminals. For that matter, maybe a settings option for adding/setting/overriding custom environment variables, so the user can CHOOSE to add appropriate options for their environment (wsl, ssh, etc).

claunia commented

@j4james commented on GitHub (Mar 9, 2022):

Color support, 16, 256, rgb including either/both delimiter options

You should be able to determine this with a DECRQSS query.

UTF-8 or not, can we find out what the character set is otherwise?

This could probably be detected by ouputting a UTF-8 character and then measuring the consumed space with a DSR-CPR query.

Image rendering support/options

You can determine Sixel image support from the DA1 report.

hyperlinks

Not possible yet, but I'm hoping to persuade other terminals to use DA1 for this to.

Regions?

Not sure what you mean.

screen size
screen resize

If you mean you want to determine the size of the screen, and whether you can resize the window, a DSR-CPR query would probably suffice.

@j4james commented on GitHub (Mar 9, 2022): > Color support, 16, 256, rgb including either/both delimiter options You should be able to determine this with a `DECRQSS` query. > UTF-8 or not, can we find out what the character set is otherwise? This could probably be detected by ouputting a UTF-8 character and then measuring the consumed space with a `DSR-CPR` query. > Image rendering support/options You can determine Sixel image support from the `DA1` report. > hyperlinks Not possible yet, but I'm hoping to persuade other terminals to use `DA1` for this to. > Regions? Not sure what you mean. > screen size > screen resize If you mean you want to determine the size of the screen, and whether you can resize the window, a `DSR-CPR` query would probably suffice.

claunia commented

@heaths commented on GitHub (Mar 9, 2022):

The issue I was trying to raise in the last couple comments above, though, is why writing to a TTY and checking the results would be the most accurate way to determine capabilities, are you expecting that every program and, more important, every shell script (especially those that want to remain simple but maybe write out some colors) have to write to the TTY, read back, then clear the line just to emit some colored output? The environment variables like TERM, COLORTERM, and TERM_PROGRAM may not be perfect but I imagine for most cases are good enough. So why not support both?

@heaths commented on GitHub (Mar 9, 2022): The issue I was trying to raise in the last couple comments above, though, is why writing to a TTY and checking the results would be the most accurate way to determine capabilities, are you expecting that every program and, more important, every shell script (especially those that want to remain simple but maybe write out some colors) have to write to the TTY, read back, then clear the line just to emit some colored output? The environment variables like `TERM`, `COLORTERM`, and `TERM_PROGRAM` may not be perfect but I imagine for most cases are good enough. So why not support both?

claunia commented

@j4james commented on GitHub (Mar 9, 2022):

@heaths I'm not expecting anyone to do anything. I'm just saying there are queries you can use if you need an accurate way to determine those features. If asynchronous queries are not appropriate for your application, or you don't particularly care whether your feature detection is accurate or not, then you can of course use any other method you prefer. As I said before, if you're happy with the limitations of environment variable, that's fine - whatever works best for you.

@j4james commented on GitHub (Mar 9, 2022): @heaths I'm not expecting anyone to do anything. I'm just saying there are queries you can use if you need an accurate way to determine those features. If asynchronous queries are not appropriate for your application, or you don't particularly care whether your feature detection is accurate or not, then you can of course use any other method you prefer. As I said before, if you're happy with the limitations of environment variable, that's fine - whatever works best for you.

claunia commented

@tig commented on GitHub (May 4, 2023):

Hi all, maintainer of https://gitub.com/gui-cs/Terminal.Gui here.

We would really like a way to ask terminals (not just Windows Term) if a specific unicode glyph is supported at runtime.

The idea being, we have to choose a least-common-denominator glyph for things like the one used for checkboxes. In this example, we choose the square root symbol as it empirically works on every terminal we've tried, with every font we've tried, where other "check mark" symbols do not.

What we'd like to do is emit a DECRQM asking, "Can you render this pretty glyph"? If the answer is no, we'll fall back to our default. If the answer is yes, we'll use the prettier glyph. We could also do this via querying an environment var or something, but it seems to me the most cross-platform way to do this is to extend DECRQM to support such a query?

I know it is possible to ask (at least on Windows) if a particular font supports a particular glyph.

I found this Issue in my searching for existing solutions to this and it seems like a good place to start. Let me know if you have suggestions on how to proceed further. My dream (big dreamer here) is other terminals will also implement such a thing in a standard way...

@tig commented on GitHub (May 4, 2023): Hi all, maintainer of https://gitub.com/gui-cs/Terminal.Gui here. We would really like a way to ask terminals (not just Windows Term) if a specific unicode glyph is supported at runtime. The idea being, we have to choose a least-common-denominator glyph for things like the one used for checkboxes. In this example, we choose the square root symbol as it empirically works on every terminal we've tried, with every font we've tried, where other "check mark" symbols do not. <img width="199" alt="image" src="https://user-images.githubusercontent.com/585482/236198028-252fe502-81aa-4bac-be28-735446dc6190.png"> What we'd like to do is emit a DECRQM asking, "Can you render this pretty glyph"? If the answer is no, we'll fall back to our default. If the answer is yes, we'll use the prettier glyph. We could also do this via querying an environment var or something, but it seems to me the most cross-platform way to do this is to extend DECRQM to support such a query? I know it is possible to ask (at least on Windows) if a particular font supports a particular glyph. I found this Issue in my searching for existing solutions to this and it seems like a good place to start. Let me know if you have suggestions on how to proceed further. My dream (big dreamer here) is other terminals will also implement such a thing in a standard way...

claunia commented