A look at terminal emulators, part 1
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
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
Posted Mar 30, 2018 20:04 UTC (Fri)
by anarcat (subscriber, #66354)
[Link] (2 responses)
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...
Posted Mar 30, 2018 20:30 UTC (Fri)
by jg (guest, #17537)
[Link]
In practice, the VT100/102/220/240 line were mostly faithful to the ANSI standard and very widespread in practice as
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
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
Posted Apr 1, 2018 22:12 UTC (Sun)
by auerswal (subscriber, #119876)
[Link]
Posted Mar 30, 2018 20:19 UTC (Fri)
by tbodt (subscriber, #120821)
[Link] (1 responses)
Posted Apr 15, 2018 13:29 UTC (Sun)
by rbanffy (guest, #103898)
[Link]
Posted Mar 30, 2018 21:01 UTC (Fri)
by eternaleye (guest, #67051)
[Link]
> “ISO 2022 locking escape sequences oh flying spaghetti monster please kill me now.” — actual USENIX peer review from the Mosh paper.
Hi Jim!
about compatibility
about compatibility
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.
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....
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
A look at terminal emulators, part 1
A look at terminal emulators, part 1
A look at terminal emulators, part 1