A look at terminal emulators, part 1 [LWN.net]

A look at terminal emulators, part 1

Posted Mar 30, 2018 19:25 UTC (Fri) by jg (guest, #17537)
Parent article: A look at terminal emulators, part 1

Venerable xterm is/was(?) unusual for having a proper ANSI terminal command parser, and so was able to pretty faithfully emulate VT100's/VT102's. I found out years later that someone in the DEC terminals group had donated code that he possibly/probably should not have.

Compliance to the ANSI standard is another axis on which terminal emulators should be judged. Doing it right is
important for application compatibility.

I don't know if the later generations of terminal emulators share that lineage (probably the only part of xterm I'd want to preserve if I was ever crazy enough to again deal with a terminal emulator; the history of xterm slightly *predates*
the X Window System itself).
- Jim

to post comments

about compatibility

Posted Mar 30, 2018 20:04 UTC (Fri) by anarcat (subscriber, #66354) [Link] (2 responses)

Hi Jim!

Compatibility is one of the features that I looked at but that ultimately didn't make it to the final version published here, because it's a really complex subject with many pitfalls. I do touch a bit on that in the Unicode and paste protection sections, but basically: it is hard topic.

The xterm FAQ makes a good review of how many control sequences are supported by various terminals, and it seems, according to the author, that xterm is way ahead of all the other terminals in that game. That certainly relates to my experience in the field as well: I often had to operate equipment using a serial console adapter, and particularly HP Procurve switches which have an "interesting" menu system. Turns out this would break down completely in anything but Xterm. In general, I have a reflex of "go back to xterm" whenever something weird happens on the terminal...

But it's tricky: the xterm maintainer also happens to be the ncurses maintainer right now, so things that are "supposed to work" are really "supposed to work in xterm". Considering that xterm's history and complexity, it's hard for other terminals to emulate correctly everything that xterm does. The fact is that xterm has become a de-facto standard on its own: anyone writing a terminal emulator now basically needs to have that as a target... Targeting ANSI, or VT100, VT102, VT202 or whatever else at this point does not make sense: there are many things that terminals do now (e.g. bracketed paste or even simply colors) that those "standards" never made any mention of. Inversely, there are many things in those standards that are not necessary in modern terminals either (e.g. printer control sequences...) Besides, I don't know if emulating only "ANSI" would bring you very far...

A whole article could be written about this, really. I'm still considering it: running `vttest` on many terminals, trying to figure out what's going on, parse the results, etc. But really, my brain still hurts from writing this piece, so it will be a while before I dare plunging into this again. ;)

As for lineage: from what I understand, only a few of the terminals reviewed here share any real ancestry with xterm. There's a whole family of xterm derivatives, but most were ultimately excluded from the review here because their are inactive upstream. As far as I know, Konsole, VTE and all the others are basically rewrites, but definitely not "cleanroom". A lot of escape sequences and logic are often copied verbatim from the Xterm source code (if not ncurses), so there is *some* heritage there at least...

about compatibility

Posted Mar 30, 2018 20:30 UTC (Fri) by jg (guest, #17537) [Link]

Curses/ncurses are a UNIX/Linux specific: lots of legacy code from other OS's don't use them at all.

In practice, the VT100/102/220/240 line were mostly faithful to the ANSI standard and very widespread in practice as
DEC terminals were very common (and not just on DEC systems); if you nail them, then you've covered just about anything software out there, as they had to be supported back in the day. And emulating them exactly was more
important than the ANSI standard itself.

The xterm secret sauce was the parser itself, which actually did parsing properly according to the standard. Thereafter it is mostly a matter of simple code and implementation. But it was hard to get the parsing right: I had to deal with that before the mentioned code donation from people in DEC (that I also worked for at the time), who were experts at
it. Life was much easier once someone else solved that problem for me (or lifted the code; as I said, I'm not convinced they should have given the code to me). It is also very possible/likely they may have reimplemented the parser rather than given me DEC copyright code: but they were true experts at terminals who did so, and may not have been properly authorized by management. We got much more careful about contributions as time went on, and DEC is long past history....

I know the actual code base used in DEC terminals was different though; that I am sure (it was on some tiny microprocessor in the terminals, and unlikely in C at all).

In the early X era, having a solid terminal emulator that really "just worked" for almost any application was one
of X's important features. And I'm oh so happy to not be the xterm maintainer (which I was for a few years early
in X...) My immense thanks to those who are....

about compatibility

Posted Apr 1, 2018 22:12 UTC (Sun) by auerswal (subscriber, #119876) [Link]

Similar to the mentioned HP Procurve switches, GNOME Terminal (and other VTE based terminal emulators) have issues with some control sequences used by the ExtremeXOS switch CLI. Using either XTerm or GNU Screen inside GNOME Terminal works around those.

A look at terminal emulators, part 1

Posted Mar 30, 2018 20:19 UTC (Fri) by tbodt (subscriber, #120821) [Link] (1 responses)

Did you know that VT100 terminals have support for double-width and double-sized text? The only terminals I have found that support it are xterm and Konsole. Nice work, Konsole!

A look at terminal emulators, part 1

Posted Apr 15, 2018 13:29 UTC (Sun) by rbanffy (guest, #103898) [Link]

While discussing it on the Vte bug tracker, someone pointed out that, since double-width/height is a line-level attribute, it'd ruin the life of people using Screen or tmux.

A look at terminal emulators, part 1

Posted Mar 30, 2018 21:01 UTC (Fri) by eternaleye (guest, #67051) [Link]

TBH, I'd much more readily take that functionality from Mosh than from xterm. To quote the webpage:

> “ISO 2022 locking escape sequences oh flying spaghetti monster please kill me now.” — actual USENIX peer review from the Mosh paper.