mirror of
https://codeberg.org/dnkl/foot.git
synced 2026-02-05 04:06:08 -05:00
readme: document XTGETTCAP behavior
This commit is contained in:
parent
5a032c4c6f
commit
da9d732855
1 changed files with 49 additions and 0 deletions
49
README.md
49
README.md
|
|
@ -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
|
||||
foot’s terminfo on remote hosts you SSH into.
|
||||
|
||||
XTerm’s 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 foot’s 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
|
||||
it’s 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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue