No support for xterm Send Device Attributes (Secondary DA) control sequence

[zrait]

Environment

Windows build number: [Version 10.0.19041.208]
Windows Terminal version (if applicable): 0.11.1251.0

Steps to reproduce

echo -e '\e[>c'

Expected behavior

A secondary device attribute response providing information that better describes what capabilities Windows Terminal actually supports.

Excerpt from xterm ctl sequences:

CSI > Ps c
          Send Device Attributes (Secondary DA).
            Ps = 0  or omitted ⇒  request the terminal's identification
          code.  The response depends on the decTerminalID resource set-
          ting.  It should apply only to VT220 and up, but xterm extends
          this to VT100.
            ⇒  CSI  > Pp ; Pv ; Pc c
          where Pp denotes the terminal type
            Pp = 0  ⇒  "VT100".
            Pp = 1  ⇒  "VT220".
            Pp = 2  ⇒  "VT240" or "VT241".
            Pp = 1 8  ⇒  "VT330".
            Pp = 1 9  ⇒  "VT340".
            Pp = 2 4  ⇒  "VT320".
            Pp = 3 2  ⇒  "VT382".
            Pp = 4 1  ⇒  "VT420".
            Pp = 6 1  ⇒  "VT510".
            Pp = 6 4  ⇒  "VT520".
            Pp = 6 5  ⇒  "VT525".

          and Pv is the firmware version (for xterm, this was originally
          the XFree86 patch number, starting with 95).  In a DEC termi-
          nal, Pc indicates the ROM cartridge registration number and is
          always zero.

Actual behavior

No response to control sequence

Why this matters right now?

When Windows Terminal sets TERM to be xterm-256color, certain popular applications expect it to respond to xterm control sequences. I came across this issue (and suspect many others have as well, although it's surprising to me that I didn't see an existing issue for it) because Emacs was hanging for 2 seconds on load whenever being launched inside Windows Terminal due to code in xterm.el (see here) (part of its terminal-capability-determination startup code) that queries the capabilities of xterm using the Secondary Device Attribute control sequence. Other terminals that masquerade as xterm (such as iTerm2, OS X's Terminal, and gnome-terminal) respond to this query.

[zadjii-msft]

I'm pretty sure we are replying to this message...

terminal/src/terminal/adapter/adaptDispatch.cpp

Lines 711 to 715 in e7a2732

	bool AdaptDispatch::DeviceAttributes()
	{
	// See: http://vt100.net/docs/vt100-ug/chapter3.html#DA
	return _WriteResponse(L"\x1b[?1;0c");
	}

Though, I just tried reading the input with a really simple script and couldn't get any input... Hmm...

[zadjii-msft]

OH you know what, I see what's happening. We're replying to the Primary Attributes request, but not the other ones.

CSI Ps c  Send Device Attributes (Primary DA).
            Ps = 0  or omitted ⇒  request attributes from terminal.  The
          response depends on the decTerminalID resource setting.
CSI = Ps c
          Send Device Attributes (Tertiary DA).
            Ps = 0  ⇒  report Terminal Unit ID (default), VT400.  XTerm
          uses zeros for the site code and serial number in its DECRPTUI
          response.
CSI > Ps c
          Send Device Attributes (Secondary DA).
            Ps = 0  or omitted ⇒  request the terminal's identification
          code.  The response depends on the decTerminalID resource set-
          ting.  It should apply only to VT220 and up, but xterm extends
          this to VT100.

[j4james]

These DA reports are on my TODO list, but I've been putting them off because it's difficult to decide what we classify as at this point. We implement sequences from a wide range of terminals, including the VT500 series, but we don't have nearly enough coverage to claim to be something like a VT500. I'm not even sure we could claim to be a VT220 yet. And since the DA2 report doesn't apply to a VT101 (which is what we're currently claiming to be), it didn't make sense to support it yet. That said, we could just go with the XTerm hack that uses 0 to indicate a VT100, and that should at least keep Emacs happy for now.

[zrait]

If you can't support the VT220 command set, I do think it makes sense to report 0 as the first digit as that does seem to be what OS X Terminal, iTerm, and gnome-terminal are doing.

[j4james]

I thought I'd do a quick PR for this now, and immediately got stuck on deciding what to use for the second parameter - what would originally have been the firmware version on a DEC terminal. Some terminal emulators use that parameter to encode their version number (e.g. VTE 0.52.2 will use 5202, and XTerm patch 354 will use 354). Others hardcode a specific XTerm patch number to try and trick applications like VIM into thinking they're XTerm, so they get features like mouse support.

If you want to see the convoluted logic that VIM uses to determine whether certain features can or can't be used, have a look at the code here. As an example of how weird this whole setup is, they have a specific check for PuTTY as reporting version 136, while PuTTY itself only chose 136 to trick VIM into thinking it was XTerm!

So the question is, what do we want to do here? I'd initially thought I could pull something from the conhost file version info. But the system conhost version is just the Window build number, which you may not want to reveal. And the OpenConsole version bundled with WT is something else entirely, which makes it feel kind of pointless. Do we just hardcode something simple like 10 (the DEC equivalent of 1.0)? Or try and pick a number that works well for VIM? I really don't know.

Bottom line is I think this needs input from the core contributors. If you let me know what you'd prefer to use for the version number, I'd be happy to put together the PR.

[ghost]

🎉This issue was addressed in #6850, which has now been successfully released as Windows Terminal Preview v1.2.2022.0.:tada:

Handy links:

• Release Notes
• Store Download

[DHowett]

🎉 As of Windows Insider build 20197, this is also supported in the traditional console.