In yesterday's entry I made the offhand comment that xterm's cut and paste was non-standard. Since this caused some confusion, it's time to amplify on that and, as a bonus, explain why xterm's model only works in rather limited circumstances.

People came up with a standard model of cut, paste, and selections very early in the history of windowed GUIs (it may date to the Xerox PARC work, I'm not sure), which goes something like this. First, there is always a selection although it may be zero width, in which case you can call it the cursor or the insertion point. If you type or paste text, the text replaces the current selection (when the current selection is zero width, this has the effect of inserting it where the selection is). You cut and paste by making a selection, invoking the 'copy' (or 'cut') operation, probably changing the insertion point and maybe the current window, and then invoking the 'paste' operation. Let us call this the clipboard model of cut & paste, after the idea that there is a clipboard that holds the 'cut' text. You can see this model even in a lot of graphical programs on Unix, and it is all over the Mac (from the early days), Windows, and most other GUI systems.

The xterm model of cut & paste is much simpler to explain and faster to use: you make selections with the left mouse button (and extend them with the right mouse button) and you paste them with the middle mouse button (where by 'paste' xterm actually means 'you send them to xterm as keyboard input', although some other X programs following this model can do a real paste).

The problem with an xterm-like copy and paste model is that it only works very well in an environment where you don't cut text, only copy it, and where you don't use 'paste' operations to overwrite text. The second is easy to see; in an environment where selecting text immediately makes it what gets pasted, you simply can't do a 'select text, overwrite it by pasting with copied text from elsewhere' operation because the moment you select the text you want to be overwritten you lose the original text you were going to paste. The first is an issue of data loss. If you actually cut text instead of just copying it, this text now exists only in your clipboard and so you don't want to have it casually discarded or overwritten; you want it to take an exceptional, explicit step, such as another 'copy' operation. Overwriting cut text by simply making a selection is too easy and leads to data loss of cut text.

(In theory, xterm doesn't have this problem because you can always go back and re-select the text you were going to copy. In practice there are a lot of ways to lose the text, such as closing the xterm with it or clearing the screen inside the xterm, and periodically this bites people.)

These limitations clearly make the xterm model not suitable as a general cut & paste model (you can argue about the 'overwrite selection' feature, but easily losing cut text is clearly bad), however convenient it is for an xterm-like situation. The standard model of cut & paste is slower but does not have these limitations, so if you have a cut operation (not just 'copy') I think that you really do need it.

(You can probably speed up the standard model by allowing chorded mouse button operations, but most interface designers don't seem to like those. I happen to disagree with them provided that the chorded mouse button operations are standard across a bunch of programs, in line with my long-standing beliefs.)

Sidebar: X's split-brain approach to this

In order to deal with the problems of the xterm approach to cut and paste, X actually has two different selection models; a selection based one and a clipboard based one. Most of the time you don't notice the difference, but there are a few programs that only read from the clipboard and ignore the current selection (and explicit 'paste' operations in programs like Firefox generally use the clipboard as the source, because they have to).