readme: document XTGETTCAP behavior

This commit is contained in:
Daniel Eklöf 2022-01-14 13:33:16 +01:00
parent 5a032c4c6f
commit da9d732855
No known key found for this signature in database
GPG key ID: 5BBD4992C116573F

View file

@ -30,6 +30,7 @@ The fast, lightweight and minimalistic Wayland terminal emulator.
1. [DPI and font size](#dpi-and-font-size)
1. [Supported OSCs](#supported-oscs)
1. [Programmatically checking if running in foot](#programmatically-checking-if-running-in-foot)
1. [XTGETTCAP](#xtgettcap)
1. [Credits](#Credits)
1. [Bugs](#bugs)
1. [Contact](#contact)
@ -432,6 +433,54 @@ e.g. “1.8.2” for a regular release, or “1.8.2-36-g7db8e06f” for a git
build.
# XTGETTCAP
`XTGETTCAP` is an escape sequence initially introduced by XTerm, and
also implemented (and extended, to some degree) by Kitty.
It allows querying the terminal for terminfo
capabilities. Applications using this feature do not need to use the
classic, file-based, terminfo definition. For example, if all
applications used this feature, you would no longer have to install
foots terminfo on remote hosts you SSH into.
XTerms implementation (as of XTerm-370) only supports querying key
(as in keyboard keys) capabilities, and three custom capabilities:
* `TN` - terminal name
* `Co` - number of colors (alias for the `colors` capability)
* `RGB` - number of bits per color channel (different semantics from
the `RGB` capability in file-based terminfo definitions!).
Kitty has extended this, and also supports querying all integer and
string capabilities.
Foot supports this, and extends it even further, to also include
boolean capabilities. This means foots entire terminfo can be queried
via `XTGETTCAP`.
Note that both Kitty and foot handles **responses** to
multi-capability queries slightly differently, compared to XTerm.
XTerm will send a single DCS reply, with `;`-separated
capability/value pairs. There are a couple of issues with this:
* The success/fail flag in the beginning of the response is always `1`
(success), unless the very **first** queried capability is invalid.
* XTerm will not respond **at all** to an invalid capability, unless
its the first one in the `XTGETTCAP` query.
* XTerm will end the response at the first invalid capability.
In other words, if you send a large multi-capability query, you will
only get responses up to, but not including, the first invalid
capability. All subsequent capabilities will be dropped.
Kitty and foot on the other hand, send one DCS response for **each**
capability in the multi query. This allows us to send a proper
success/fail flag for each queried capability. Responses for **all**
queried capabilities are **always** sent. No queries are ever dropped.
# Credits
* [Ordoviz](https://codeberg.org/Ordoviz), for designing and