xterm's cut and paste model is non-standard and limited
In yesterday's entry I made the offhand
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
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.
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
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
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
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).