CHA-TERMINAL(7)
โจ Chawan terminal compatibility โจ
okay so bestie, this is CHA-TERMINAL(7) โ the vibe check on how Chawan talks to terminals. Chawan does not use termcap, terminfo, or ncurses; it relies solely on built-in terminal handling routines, mostly inspired by notcurses. periodt ๐
๐ป XTerm compatibility ๐ป
In general, Chawan assumes an XTerm-compatible environment, where โXTermโ means the current XTerm version as developed and maintained by Thomas E. Dickey. That means Chawan is compatible with any given terminal if:
- the terminal is actually compatible with XTerm, OR
- the terminal isnโt compatible with XTerm, but reports its capabilities via terminal queries correctly, OR
- the terminal isnโt compatible with XTerm, but its
TERMvalue is hardcoded in Chawan.
Terminals pretending to be XTerm (TERM=xterm) which are not actually XTerm might malfunction. ๐ซ
lowkey reassurance: in practice, the author has tested dozens of terminal emulators and hasnโt encountered any major issues; in all likelihood, yours will work too. If it doesnโt, please open a ticket. ๐๏ธ
๐ Queries ๐
Queries are preferred to hardcoded terminal descriptions because they are forward-compatible. On startup, Chawan queries:
- Whether the terminal has true color, with
XTGETTCAP rgb. - The default background, foreground, and 16 ANSI(-ish) colors with
OSC 10 ; ? ST,OSC 11 ; ? ST, andOSC 4 ; {0..15} ; ? ST. OSC 60 STandOSC 61 allowWindowOps STfor detectingOSC 52support (see the Clipboard section). ๐- Whether the terminal can use the Kitty image protocol, by sending a
1x1Kitty image and listening for a response. - The number of Sixel color registers (
CSI ? 1 ; 1 ; 0 $). - Primary device attributes (
DA1). - Text area and cell size using
CSI 14 tandCSI 16 t. (Cell size beats text area size as it is more reliable.) - Window size in cells by sending a
CUPto9999;9999and then asking forCPR(the same trick is used byresize(1)).
Chawan processes responses to the above query in the same state machine as user input, so it works reasonably well on all terminals that at least emulate the most basic VT100 function (CPR). This unified state machine also minimizes the chance of user input being mistaken for a query response (or vice versa). slay for not mixing up your keys and terminal replies ๐
โ ๏ธ Terminals that do not respond toCPRwill freeze on quit โ in this case, you must typeC-cto forcibly kill the state machine. In practice, FreeBSDโsvt(4)is the only one the author has found that exhibits this behavior; to add insult to injury, it claims to be an โxtermโ inTERM. Therefore we discriminate betweenvt(4)and a real XTerm using anioctl. (Idea shamelessly stolen fromnotcursesโ Linux console detection.) ๐ญ
Some terminals bleed the APC sequence used to recognize kitty image support, and this may result in strange artifacts when no alt screen is used. On affected terminals that set TERM correctly, the APC sequence is not sent.
๐ Clipboard ๐
Some terminals support sequences to override the clipboard. Chawan differentiates between three tiers:
- Supports clipboard and primary selection. The latter is what allows you on X11 to select some text with the mouse and then middle-click paste it elsewhere.
This applies to all terminals that respond to OSC 60/61 (XTerm) as well as a hardcoded list of terminals that respond with 52 in DA1 and have been confirmed to support the primary selection (Kitty). ๐ฑ
- Supports clipboard, but may choke on trying to set primary selection.
This applies to terminals that include the number 52 in DA1. This response guarantees nothing about support for the primary selection, and indeed, some terminals that return it (e.g. Contour) behave incorrectly when receiving primary. ๐
- Does not support clipboard. In this case we shell out to
external.copy-cmd(defaults toxsel(1x)).
This applies to all other terminals. Notably, this includes terminals that support OSC 52 but do not have a reliable mechanism to detect whether it actually works, such as Alacritty.
It is possible to manually adjust OSC 52 use with the input.osc52-copy and input.osc52-primary configuration options. ๐
๐ฆ Ancient terminals ๐ฆ
Most pre-ECMA-48 (1979) terminals are not expected to work.
There is some degree of ADM-3A support, tested in Kragen Javier Sitakerโs admu emulator.
Some DEC terminals have also been tested in simulators of the original hardware running the actual ROM:
- The VT100 has been tested in Lars Brinkhoffโs
terminal-simulator. Note: useTERM=vt100-navif you donโt have advanced video. - The VT420 has been tested in Matt Mastracciโs Blaze.
Patches for other terminals (hardware or software alike) are welcome. ๐ซถ
๐ง Ancient character encodings ๐ง
For ASCII-only terminals, donโt forget to export LC_ALL=C. For terminals supporting other legacy encodings, you may also have some luck with setting it to language.charset, such as export LC_ALL=ja_JP.ISO-2022-JP.
Note that Chawan uses its own encoding library instead of the notoriously broken C locale facility, and the two sets of supported charsets may not fully overlap. You can test whether a charset is supported using cha -O {charset name} -V.
๐ See also ๐
okay bestie, thatโs the whole CHA-TERMINAL(7) page โ the original footer didnโt give a separate source/version/date, just the manual name, so hereโs your cute sign-off: stay terminal-iconic and may your queries always come back in the same state machine ๐โจ๐ฆ
๐ฆ where this page comes from
- arch rolling: chawan 0.5.0-1 ยท Unlicense
- ๐ girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms