The importance of xterm for X Windows

May 3, 2011

In an earlier entry I said that you could make a strong case that X succeeded because its authors spent so much effort on making xterm a good terminal emulator. Today I feel like explaining that.

First, let's be clear that xterm was (and is) a very good terminal program. It was fast and responsive, it worked well, it emulated almost everything that a very popular real terminal did (which was important because at least some things basically assumed that they were talking to a vt100-compatible terminal), and it had excellent cut and paste support for straightforward text. These were not necessarily common attributes in terminal programs at the time (and even later; NeWS had a famously slow terminal emulator if I remember correctly).

(People sometimes knock xterm's cut and paste support as being non-standard. That is true, but its cut and paste support is also extremely fast and easy to use; if you are going to use it a lot, this matters much more than having a slower but more standards compliant version.)

This mattered because almost everything people did in new Unix windowing systems at the time was, well, run terminal windows. This is because the new windowing system wasn't going to start out with very many desirable graphical programs for it (and X certainly didn't); as a result, most of what people did with it was run their existing terminal-based programs in terminal windows. How nice those terminal windows were thus made a big difference to how enthused people were about the overall windowing system; a bad terminal program made the whole system unpleasant or annoying to use, while a good one made it a pleasure.

(The web has changed this drastically; these days the majority use of any graphical system is probably to run a browser. But this was back in the mid to late 1980s and early 1990s.)

My strong impression is that a lot of the competing window systems considered their terminal program to basically be an afterthought (which resulted in the sort of terminal program that you'd expect); most of their focus was on building a graphical toolkit and then some number of graphical programs to alternately show it off or do useful work. The problem was that of course these systems could never build enough graphical programs to make the terminal program unnecessary, even if Unix people at the time had been willing to give up the command line. The result was that in practice the experience of using those systems tended to be kind of unpleasant unless you were doing something that their particular set of GUI programs were good at.


Comments on this page:

From 138.246.23.74 at 2011-05-03 14:23:04:

Not sure what you mean by "non-standard cut and paste", but in my experience (u)rxvt beats xterm in speed and has very useful additions (e.g. rewrapping lines instead of clipping when you change the terminal size). Also, the xterm source code is truly hideous; there are files where 20% of the code are #ifdef!

The main feature of xterm is that it is installed on every X setup, and with Xorg, not even that is sometimes the case.

By cks at 2011-05-03 17:21:04:

This entry is about the early days of X (and the early days of other windowing systems); back in those days there were no alternatives to xterm on X. I would certainly hope that any other terminal program on X would do better than xterm, because otherwise why write it in the first place?

(Okay, some people demand that their particular UI toolkit have a terminal program that fits into it and is 'easy to use'. But even with that, I think that gnome-terminal and konsole are in their own ways better than xterm in some aspects.)

By non-standard cut & paste I mean that xterm's cut & paste doesn't use the model of 'make selection, invoke copy via menu or keystrokes, invoke paste via menu or keystrokes' that you see in standard GUI programs such as Firefox (or any number of things on Windows, Mac, etc). Instead it hijacks all three mouse buttons for speed and ease of use (and in a way that only really works for non-destructive copy & paste).

(Okay, Firefox sort of concedes to xterm's influence on Unix. I don't know if it still does middle-mouse-paste on other platforms.)

From 78.35.25.22 at 2011-05-03 18:11:33:

That’s not non-standard copy&paste. X11 has left-drag to select and middle-click to paste as a separate mechanism distinct from regular copy&paste (which is also supported). It’s how things were supposed to work on X11, and in fact still do. The gesture worked in all the toolkits of X11’s early life and continues to work in all the modern toolkits I can think of – except, possibly, Qt. (Or else few Qt applications implement support, I don’t know. I’ve never been an enthusiast and this is one of the reasons.)

Aristotle Pagaltzis

By cks at 2011-05-04 01:41:06:

I've tried to explain myself on the 'non-standard cut & paste' issue in CutNPasteModels, although I may not have succeeded.

(I half-agree that the xterm cut & paste model is not all that non-standard for X but I think there are important caveats there, mostly to do with the lack of true 'cut' operations in early X programs.)

Written on 03 May 2011.
« The apparent origins of some odd limitations in the iSCSI protocol
Why xterm's cut and paste model is non-standard and limited »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue May 3 01:15:22 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.