It is "Send Device Attributes (Secondary DA)", according to XTerm Control 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 setting. It should apply only to VT220 and up, but xterm extends
this to VT100.
The control (applied to VT220, etc.) is documented in DEC manuals on vt100.net
The point of Send Device Attributes is that a program is asking the terminal something. The terminal sends back information, the response. This happens to be a string that looks something like the request (which is helpful if the terminal is not really connected to a host). The program which sent the request has to read the response, otherwise you will see odd characters printed on the terminal—the unread parts of the response.
In the context of your question about vi, vim uses this to determine the version of xterm which it may be using. The answer is provided in the response from the terminal:
and Pv is the firmware version (for xterm, this was originally
the XFree86 patch number, starting with 95). In a DEC terminal, Pc indicates the ROM cartridge registration number and is
always zero.
The particular feature in vim which is using this is called "termresponse". If you use it on a terminal which pretends to be xterm, but is not really, then you will see stray characters on your terminal, as described in an answer for Why is vim starting in delete mode?. Any terminal emulator which is "VT100 compatible" must handle this, however.
The following ESC[1;1H
is not related to the Secondary DA, but rather is standard (ISO-6429 / ECMA-48) cursor-positioning done for initialization (and you would see something like this in any text editor running in a terminal). Usually it is sent in a shorter form, ESC[H
, since the numbers default to 1
.
The ESC[>c
is a private mode sequence, as indicated by the >
character. That (and many other details) are described in ECMA-48. DEC's terminals followed the standard, along with extensions. The "ANSI" standard for terminal controls was long ago subsumed into the ISO standard, and (still) long ago the corresponding ANSI standard was withdrawn.
You would be unlikely to encounter this sequence used in communicating with a hardware terminal, since it was (before xterm began using it in the 1990s) predominantly used by DEC's (Open)VMS systems to determine what types of terminals were connected to it.