Terminal: Eventually register a terminfo with ncurses upstream

[fpqc]

Thomas Dickey, the maintainer of the ncurses project, also maintains the terminfo-db distributed with most Linux distributions. At the moment, the main TERM environment variable is xterm-256color, but not all xterm features are supported or even planned. When 1.0 releases, it would be good to leave xterm-256color as the default TERM environment, but also to maintain a separate terminfo with the ncurses project upstream. This means that as the changes in ncurses propagate down to the distros, the team can make a switchover and report the TERM as ms-terminal.

This will give the team the freedom in the long-term to add new features not implemented in xterm (for example, to support 32-bit color (i.e. an alpha channel)) or any other cool features they might dream up. Some projects like libvte and kitty have or previously had a bad relationship with the ncurses maintainer because they refused to submit their own accurate TERMINFO to the database.

[DHowett-MSFT]

Related: #1040

We've actually been in touch with Thomas about the existing ms-terminal termcap, which _is_ derived from some amalgamation of Windows Terminal and conhost's capabilities. For a while, too, we've been talking about whether we should ship one with Windows as well.
It's slightly more complicated because both Windows Terminal and conhost have different capabilities. The latter is more robust, but eventually they'll line up (right now, WT is weaker because it has conhost translating for it.)

[fpqc]

@DHowett I actually have a question about that: Are you eventually planning on having WT do its own VT processing/rendering via a raw pty (but still using the shared renderer library) instead of having conhost do it? This would make things a lot easier to divvy up by profile, in particular this feature https://github.com/microsoft/terminal/issues/2946

[DHowett-MSFT]

For that one, you'll want to track #1173. It's our (rough, mostly "we should do this") plan to converge the output engines for WT and conhost at some point.

For #2946, it's probably sufficient to parse but _fail_ (ignore) OSC 52 when the console host is in VtIo mode, which will get conhost out of the way and give WT full control over what it does with the sequence.

[fpqc]

Very good! That was one solution I had already considered, but I wasn't sure if the maintainers would be happy with it.

[sandorex]

Has there been any progress on this? Does the terminfo exist just not in the upstream of curses?

[zadjii-msft]

@sandorex Nope, when there's progress, we'll make sure to post here 😉. For all intents and purposes, the Windows Terminal should be treated as xterm-256color, and any bugs that might arise from that should be filed _here_, so we can close any remaining gaps.

[sandorex]

@zadjii-msft to be clear that does not include conhost, just the new terminal?

[zadjii-msft]

_Technically_, that's specific to conhost. The Terminal is currently powered by conpty, which uses conhost as a middle-man to translate console API calls into a stream of VT that the Terminal can understand. Part of what conpty does is also parse all the VT on behalf of the Terminal. It's not terribly efficient, but it gets the job done.

Conpty only ever emits a few types of sequences. It doesn't need the full range of VT to be able to recreate the console buffer. Since conpty is always sitting in the middle, Terminal is actually _far below_ xterm-256color in terms of support. Fortunately, we don't need to worry about it for now, since conpty is always there to act as xterm-256color. The work to hopefully _not_ do this double parsing is being tracked over in #1173

[sandorex]

Honestly this is confusing me a bit

erminal is actually far below xterm-256color in terms of support. Fortunately, we don't need to worry about it for now, since conpty is always there to act as xterm-256color

How should The Terminal be treated, as partial xterm-256color ? experimental / unstable ?

[zadjii-msft]

Oh no, the Terminal is always attached to conpty, and conpty is just conhost. Conhost is xterm-256color, so the Terminal is _effectively_ xterm-256color. That's how you should treat the Terminal as a black box. I confused you by providing some unnecessary implementation details 🙃