At this point, there are hundreds of graphical terminal emulators out there. Every single one that I have run into pretends like it is some varient of a hardware terminal made by Digital Equipment Corporation (DEC) from their Video Terminal (VT) line of products, from 1978’s VT100 through 1993’s VT525.
A reader might chime in here and say, no MY TERMINAL thinks it is an
xterm pretends to be a VT420 (
xterm can actually pretend it is
many different terminals, so even if you DO use THE
xterm software I doubt
your computer is actually set up to most efficiently talk to it, I’ll talk
about that later ).
First, the language a computer uses to access a terminal’s capabilities like, clear the screen, move the cursor, start printing inverse color, etc., are called Control Codes. Second, is that there was a standard created for control codes: ANSI X3.64-1979 The first product to market to mostly follow these standards was the DEC VT100 (several months before they were published).
This document, which I’ll refer to as The Standard, isn’t easy to read
because it refers to characters not by the common GLYPHS and Abbreviations
we are used to seeing in a common ASCII chart, but instead a 4/4 bit split,
? is referenced as
5/15 which these days would be talked
about in HEX
x5F, and this notation is true throughout The Standard.
The Standard also makes it clear that NO single product is expected to implement every code but should be aware of the paramters for codes so that a product can know to ignore the codes it doesn’t implement. With the exception of iTerm2, every Terminal I’ve used mostly follows The Standard.
The Standard’s Non-Standard Carve-out
The Standard specifies that there are four entries to special controls; SS2, SS3, ESC and CSI. The SS (Single Shift) entries aren’t relevant here, but the ESC and Control Sequence Introducer are relevant.
ESC is character
x1B. The standard only assigns four functions
that exist past an ESC without the
x58) which turns it into
- 8-bit ASCII: CSI is a standalone character,
- 7-bit ASCII: CSI is two characters:
Unicode only preserved the 7-bit ASCII table, and CSI being in the 8 bit range, moved the CSI into a different place, so unless a terminal emulator still uses a retro-8bit ASCII code-page mode, it is easier to use the 7-bit control varient given that Unicode CSI doesn’t save any transmitted bits.
After the CSI, The Standard suggests that parameters can start. The first
position of the first parameter, though, is restricted.
x3B indicates something that is either
defined by The Standard or reserved for future standards. However,
x3F ) are reserved for
“Private Parameter”. This means that this indicates something that will
never be defined by the standard, and is a safe place to indicate feature
parameters that are not covered by The Standard.
DEC Video Terminals and the Device Capability Feature
Before the standard, The DEC VT50 had a control initiated by
ESC Z which
DECID is NOT one of the four “ESC Fn” codes in
The Standard. The DEC VT100 would also respond to this, but it was
not part of The Standard, and the manuals begged users to stop relying
on its existence (VT400 and later terminals ignore it).
DECID, DEC instead did something more weird.
They created a control called
Device Attributes (DA) which was accessed
CSI c (
ESC [ c). This gets a bit complicated but
c is inside the
range of characters reserved for future standards, so it should not have
been grabbed by DEC for this function.
That is I’m starting out to say that DEC itself doesn’t fully follow The Standard. I would guess they figured if they sold enough terminals, nobody would assign something else to that function, and, well, they were right in taking that gamble.
Later, with the VT220, they kept
Device Attributes but also added what
they called a
Secondary DA. That DID follow The Standard:
CSI < c,
which uses the
< character to designate that this is, at least, a
“Private Parameter”. Though the final function still shouldn’t be
setting a Private Parameter, is at least makes other ANSI compliant terminal
know to not try to figure out the meaning, even were
c to be given a
standardized function meaning later. Good job on the bare minimum.
Secondary DA would return the sub-model within a range, a firmware version
of the terminal, and an indicator of hardware feature (special keyboard or
internal modem). Outside of
xterm itself, all Terminal Emulators I have
tested pick some numbers, and never change it no matter how much the
software itself changes.
Most currently maintained Terminal Emulators respond to
Secondary DA, even if the
Device Attributes response indicates a
VT100 model that didn’t support the secondary feature. Note that the VT400
line also introduced
Broken Terminal Emulators
Claiming to Be, But Not Actually
Several terminal emulators take a
safe route by claiming to be a
VT100 or VT102. Since this is the first ANSI Escape sequence terminal,
they have less features than subsequent Video Terminal models.
\033[?1;0cVT100 without Advanced Video Option (AVO)
\033[?1;2cVT100 with AVO (underline, blink, bold, reverse video)
\033[?6cVT102 zero option version of the VT100
Terminal emulators that claim to be a VT102 or VT100 without options are claiming that they cannot even do underline, bold, blink or reverse video. Yet, all of them can do these things (or, at least they’ll use brighter colors to emulate Bold, which a VT100 couldn’t do).
VT200 and higher terminals have controls to protect an area of the screen from overwrite or overrun. Few terminal emulators can do this correctly. That requires programs to be extra careful to wrap their own text to stay out of protected areas (that aren’t actually protected).
Mislabeled Device Attributes
DEC terminal products from VT200 included a DA response that listed out
features numerically. Has printer, has alternate code-page, has graphics,
xterm does a good job emulating these correctly, but many
terminal emulators seem to just put something else’s answer in as the return.
\033[?62;4cVT200 ONLY 80 columns supporting sixel graphics.
Does it Really support Sixel?
xterm does in the right emulation mode,
iTerm2 does. If not, don’t do this.
\033[?65;1;9cVT540 supporting 132 character width and 7bit National Replacement Character sets.
For those that talk Unicode, option 9; 7bit National Replacement Character Sets, doesn’t really make sense anymore.
The DEC VT340 and VT525 products did color. If your terminal emulator does
support color, maybe try emulating one of those models? But no,
“I’m a VT100” respose probably also means “I can do color”.
Nothing indicates color depth either.
xterm DA will include a 22 to
indicate color support, but is that 8, 16, 88, 256 or even Direct Color?
“Direct Color” can theoretically support 48 bit color. Nothing is
available to tell the software which is available. Sigh.
Unicode was first published before the last DEC terminal was designed, but it was hard-coded 16-bit (two byte) at the time, and had far more code points that most Terminal buyers would need anyway. That is, the VT500 series was still 7 or 8bit ASCII with swappable code-pages.
Since 1994 and the last DEC Video Terminal debut, UTF-8 has slowly
become the defacto standard, and terminal emulators have been quietly adding
support for UTF-8, led (as was the typicaly case) by
xterm didn’t add a response number to indicate UTF8, nobody else did
either. That means there’s no way for a program to ask a terminal if it
is expecting ASCII or UTF-8. After 2010, most programs just assume that
UTF-8 will be accepted but that’s a weird expectation.
This ALSO means that even terminals that claim to be an 8bit capable
DEC terminal just no longer support the
CSI character (under Unicode,
it is no longer a single byte, but was moved into a two byte range, yet
that isn’t a valid reason to drop this support entirely).
This didn’t matter much in the days of 7bit ASCII, but in the Unicode era it would be super helpful for a program to be able to ask the terminal if a certain codepoint can actually be printed or not. If my program wants to drop a beer emoji (like homebrew), I have to do a lot of guess-work to figure out if that is possible. Worse, if my terminal program wants to print traditional Chinese characters as still used on the island of Taiwan, I no longer have a way of checking if such a thing is available.
iTerm2 abusing The Standard
iTerm2 does this weird thing of introducing new controls in reserved space,
with several new controls that start with
ESC ] 1
which doesn’t start with the CSI (that terminals were taught to ignore if
they don’t understand them), and ends with The Standard’s 7bit
It makes the Zeroth Parameter into a Sub Function designator and the Oneth
Parameter into a Sub Function selector.
Terminal capabilities and Terminfo
There’s this great bit of software and sets of libraries that are able to map a terminal’s capabilities into the Control Codes that that terminal ACTUALLY uses. There’s even a very extensive file that includes those definitions for a huge number of terminals and terminal emulators.
Do you use the new
Windows Terminal on Win 10 or 11? That one’s
entry is ms-terminal. Do you use the default
Terminal.app on macOS?
That is nsterm. What about
Konsole (konsole) or
Gnome Terminal (vte)
on Linux. How about
xterm … uh… Well… That’s a problem.
If you actually use xterm (it’s ugly and few people can tolerate it these
days), then you actually DON’T want to use the
xterm entry at all.
xterm-256color entries are purosely hobbled because
most modern terminal emulators ask for the
xterm entry, claiming
compatability, when they just aren’t fully there. That means, the
xterm entry is a pared down entry of VT102 basic controls that
everyone generally has, forcing software to do things with padding
or extra cursor moves because actual features are reported as
missing … for the lowest common denominator.
Being Awkwardly Good: KiTTY
I won’t use it because it forces
bash into POSIX mode
on purpose, but as far as a terminal emulator, the KiTTY terminal
emulator is awkwardly good. It does NOT ask to be treated like an
xterm like everything else. Instead it installs it’s own terminfo
xterm-kitty, awkward name, but unique), and with ssh
integration it will even forward its own entry to any computer you
log into. It’s a rare case where even if KiTTY does everything else
wrong, it doesn’t matter because a program can trust that it has the
best terminal definitions avaible already.
Writing a Terminal Program?
Stop Pretending to be Something Else
Please do support the
Secondary DA and
entries, but don’t reply with stock answers. Let it be the different thing
that it is.
\033[?13;...cThere was never a VT that answered between 13 and 61.
\033[?66;...cThere was never a six series VT, it’s there and open.
New Feature Flags
The highest feature number I’ve seen is
Go ahead a reserve a feature number for explicit UTF-8 support. The first one to do it and document it is likely to become the standard maker.
Go ahead and make a scheme for color supports. 8, 16, 88, 256, and Direct are all out there, but don’t have option numbers.
Will this be the first one to add a feature for telling a program if a Glyph is printable? Will this be the first one to have a way to explicitly say how wide a glyph actually will print?
Learn from KiTTY, supply a terminfo entry.
Even if a terminal emulator is designed to be compatible with the stripped
xterm terminfo, if it has ANY features beyond that, it should start
shipping a terminfo source file with all of its features.