WT should set COLORTERM

[heaths]

Description of the new feature/enhancement

Related to #1040, WT should set the COLORTERM environment variable to "truecolor" since WT does support truecolor. I can understand how changing TERM to "xterm-truecolor" (from "xterm-256color") could be a breaking change, but that's what COLORTERM is for.

Some tools like with cli/cli#4079 use this to determine if 24-bit colors should be emitted. Easy enough for users to define - either as Windows environment variables or update their shell profile e.g., .bashrc, but users who don't know what won't enjoy a wash of color by default like with gh issue list starting with v2.0.0.

Proposed technical implementation details (optional)

WT should ideally define the environment variable COLORTERM=truecolor within its own process environment block by default.

/cc @mislav

[WSLUser]

Related: #8303. Might get duped into that one. Also related but was closed as something they're not willing to do as infocmp doesn't exist nor planned to exist: #8336

[zadjii-msft]

Discussed this with Dustin last week - I think we're both cool with this now. I think we were both more reluctant to do it in the past because it's just not a great solution, but it works for most people. So we may as well, same with TERM_PROGRAM and TERM_PROGRAM_VERSION. If people really want to take dependencies on these three, then why not?

[heaths]

@DHowett, @mislav for truecolor-detection support, is this really the right detection then? There's mention of many different TERM values that wouldn't match these checks. Seems TERM has become grossly overloaded and it's hard to glean anything consistent from it.

From a quick search for COLORTERM, it seems its usage is just as convoluted as TERM. Perhaps the only reliable way is to do something like this, which I've seen mentioned elsewhere.

[zadjii-msft]

Perhaps the only reliable way is to do something like this, which I've seen mentioned elsewhere.

Woah, I've never seen that particular sequence (\eP$qm\e) used before. I don't think we support it, so that definitely won't work right on Windows (conhost or Terminal). We also don't support the colon syntax for RGB colors currently, #4321. (aside: when did that version get so popular? I swear I only ever saw the semicolon version years ago when I first implemented RGB support).

You might be able to get away with just adding a if runtime.GOOS == "windows" if you can be relatively certain that the code is running on Windows 10. RGB support was added in RS2, so there's only 3 releases of Windows 10 that didn't support it (TH1, TH2, RS1), and even then VT support was only added in TH2 in the first place. Granted, I'm no golang user myself so if you need to be more precise than that, I won't be any help :P

[WSLUser]

https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences exists and notcurses is using it for the new experimental support of Windows. Notcurses in facts manipulates the terminfo entry to grab what it needs for the various terminals. There's no denying that terminfo isn't the greatest solution but no consensus appears to have been reached for implementing a standardized query method for terminals to use so any terminal that does have a query detection feature implements it in different ways, which does in the end rely on terminfo at some point.

(This all being said, WT is certainly able to create it's own query method that reflects that doc, but since there are other terminals on Windows to account for, the env vars would still be needed for them)

[heaths]

With that in mind, it really seems like there's no good solution since the CLI supports pre-Windows 10 as do many apps out there.

So would just trying to emit an RGB VT sequence be best? If a terminal doesn't support it, it should just ignore the sequence and emit text with the default background and foreground colors, right? So there's really no point in trying to detect if truecolor is supported?

/cc @mislav

[mislav]

If a terminal doesn't support it, it should just ignore the sequence and emit text with the default background and foreground colors, right?

It should but doesn't always. Terminal.app does not support RGB colors and yet outputs strange formatting when you try to use RGB sequences. As long as the default terminal emulator on one of major operating systems can't get this right, authors of CLI apps such as myself will rather want to operate on detection rather than blind faith. Plus, we might want to output 256-color to clients that do not support truecolor, rather than outputting truecolor and have it be rendered with default foreground+background.

for truecolor-detection support, is this really the right detection then?

I don't know! That's the best (read: easiest, most straightforward) that I saw various CLI tools come up with.

[heaths]

As long as the default terminal emulator on one of major operating systems can't get this right, authors of CLI apps such as myself will rather want to operate on detection rather than blind faith.

Totally makes sense and I agree. It's just strange that, at least when it comes to colors/VT support, writing console apps seems to be harder/more involved than writing windowed apps. 🙄

Still, the crux of this bug: if COLORTERM is meant to detect color support - though what the value is set to doesn't seem well-defined - perhaps the more oft-supported TERM=xterm-256color is appropriate here for WT while COLORTERM=xterm-truecolor is appropriate in addition. TERM seems to be more general-purpose from various reads, while COLORTERM seems to be more specific to color support, as the name also implies.