Please report XTVERSION in response to CSI > 0 q or set TERM to something other than xterm (or both)

[chaosemer]

Description of the new feature

Ideally I think Windows Terminal would set the environment variable TERM to a unique value and also update the existing terminfo databases. However, I understand that the intermediate state that creates where many programs don't recognize the new terminal type is undesirable.

So in the meantime, can Windows Terminal report XTVERSION? From ctlseqs:

CSI > Ps q
            Ps = 0  ⇒  Report xterm name and version (XTVERSION).
          The response is a DSR sequence identifying the version:
            DCS > | text ST

This escape sequence is pretty widely supported to send a unique string that identifies the name and version of a terminal. Off the top of my head, VTE-based terminals (such as GNOME Terminal), Konsole, iTerm2, WezTerm, Contour, and kitty all support this escape sequence.

Context: I am currently drafting up a patch to Emacs that will rely either TERM or XTVERSION to determine if xterm-mouse-mode is safe to be enabled by default. Emacs wants to see support fo OSC52 copy, bracketed paste, DECSET1000, and DECSET1003 at a minimum and checking XTVERSION or TERM is the only way I have to identify if these escape sequences are supported. Also see Emacs discussion thread.

Proposed technical implementation details

No response

[DHowett]

Thanks for the report! Unfortunately, we're not the ones setting TERM...

Even so, we strive for some measure of xterm compatibility. There's a lot of discussion over in #1040 that I won't rehash over here, but suffice it to say that we're in a less-than-ideal situation.

Therefore, we definitely should report something for XTVERSION. 🙂

[chaosemer]

When this gets addressed, please share the format used so I can add Windows Terminal to Emacs' list. Windows Terminal otherwise supports all necessary functionality and as it is becoming the dominant terminal on Windows I would like for it to work by default.

There are two response formats I've seen for the string:

NAME VERSION, like "iTerm2 3.5.10"
NAME(VERSION), like "kitty(0.38.1)"

Either is fine for parsing, Emacs is matching a regular expression to extract the terminal program name. I think the second version (with parenthesis) is slightly more often used.

[DHowett]

One interesting wrinkle here is that we have three or more distributions that all offer the same VT support. Ideally we would avoid XTVERSION becoming another User-Agent, but we have:

• The Windows inbox console host, versioned with windows
  • conhost(10.0.19041.0)
• The console host as built out of this repository, versioned with Terminal
  • conhost(1.22.3651.0) or equivalent version conhost(1.22.2412.31001) (bah)
• The terminal application shipped out of this repository, versioned as itself
  • WindowsTerminal(1.22.3651.0) or equivalent above

These are, if I squint, just fine. The Windows version one is annoying because we have not (yet!) documented the effective version equivalence between Windows and Terminal. We can and should. The fourth distribution sucks:

• The reusable Terminal UI control, shipped in Visual Studio or [insert app here], versioned with Terminal
  • TerminalControl(1.22.xyz.abc); however, it may be important for the application hosting the reusable terminal control to indicate what they are, because they can control (to an extent) which terminal features are available.
    • VisualStudio(17.4.3)+TerminalControl(1.22.xyz.abc)

NB: I am not currently signing up for any of these names or semantics; examples above are illustrative.

I wonder how libvte handles this.

@j4james is there prior art you can think of for this report?

[j4james]

I know at one point VTE were considering how this would interact with the terminals that depend on their library, and they discussed potentially having something like VTE 0.78.2 (GNOME Terminal 3.36.0). But as of right now I think they simply report VTE(7802).

Personally I think we should jump straight to something like

Mozilla/5.0 (Windows Terminal 1.22; Win64) XTerm(397) VTE(7820) Konsole iTerm2

Because that's likely what it's going to devolve into in the long term. At the very least we should make it an editable option so users can override it when they need to get the terminal working with some stupid app that is hardcoded to only work with a specific set of XTVERSION responses.

[chaosemer]

You forgot the "(like VTE)" part of the user agent. Clearly it's Mozilla/5.0 (Windows Terminal 1.22 like iTerm2; Win64) Konsole. (The previous sentence is a joke.)

My observation is aligned about VTE. VTE terminals all respond with just "VTE(7592)" and no other details about the wrapping program. So maybe something like WindowsTerminalControl(9001) is sufficient, similar to VTE.

I separately have ideas about creating a probing mode where each escape sequence can get a reply from a terminal if it is supported or not. However for that to be useful it would require multiple terminals to all adopt this escape sequence which will take much longer than just this one feature request. :)

[j4james]

I separately have ideas about creating a probing mode where each escape sequence can get a reply from a terminal if it is supported or not.

Most of the functionality you need to query can already be probed with existing standards. For example, all of the modes you referenced above can already be queried with DECRQM.

The only thing that isn't currently detectable is OSC 52, and that could easily be added to something like the DA report if a few terminals could be persuaded to agree on a number, and perhaps a minimum level of functionality. That's more sensible than you trying to manage a constantly growing list of terminal names and version numbers, and/or expecting new terminals to notify every application that's using XTVERSION of their existence.

Not to mention the fact that XTVERSION isn't a reliable way of determining whether OSC 52 will work anyway. You may know that a particular terminal supports OSC 52 in general, but you can't tell whether a particular user has disabled that sequence for security reasons.

So maybe something like WindowsTerminalControl(9001) is sufficient, similar to VTE.

As @DHowett mentioned above, there are multiple terminals sharing the VT code base used by Windows Terminal. However, they don't all share the same functionality, so if this value were the same for all of them, and you were using the name for feature detection, it's not going to work. The same thing likely also applies to VTE for that matter.

[hzeller]

I am in favor of being specific, so WindowsTerminalControl(9001) sounds good to me, but a response that contains all kinds of terminal flavors just because someone might attempt to match these is not useful at all.

Case in point: In timg, the XTVERSION query is one of the ways to figure out what potential available features there are. Reporting terminal names that support more features than actually available will result in a bad experience (e.g. Konsole supports iterm2, kitty and sixel image formats, iterm2 supports iterm2 but no other - while windows terminal supports Sixel).

So from a 'I am a user of the information' perspective: being specific is good.

[chaosemer]

Most of the functionality you need to query can already be probed with existing standards. For example, all of the modes you referenced above can already be queried with DECRQM.

The only thing that isn't currently detectable is OSC 52, and that could easily be added to something like the DA report if a few terminals could be persuaded to agree on a number, and perhaps a minimum level of functionality. That's more sensible than you trying to manage a constantly growing list of terminal names and version numbers, and/or expecting new terminals to notify every application that's using XTVERSION of their existence.

How do do I query that DECSET 1000 (mouse button reporting), DECSET 1003 (mouse move reporting), or bracketed paste are supported? I did not see any such capabilities in the linked guide.

Not to mention the fact that XTVERSION isn't a reliable way of determining whether OSC 52 will work anyway. You may know that a particular terminal supports OSC 52 in general, but you can't tell whether a particular user has disabled that sequence for security reasons.

Yes, this is a downside. I certainly would prefer a way to determine the actual support if possible. At the moment, I am only making a judgement based on a reasonably available terminal version (sadly, this is subjective) default behavior. This is clearly going to fail for some users. I expect the number of users surprised to be quite small, though.