about compatibility [LWN.net]

about compatibility

Posted Mar 30, 2018 20:04 UTC (Fri) by anarcat (subscriber, #66354)
In reply to: A look at terminal emulators, part 1 by jg
Parent article: A look at terminal emulators, part 1

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...

to post comments

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.