Why xterm's cut and paste model is non-standard and limited

May 4, 2011

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


Comments on this page:

From 171.69.137.181 at 2011-05-04 19:05:23:

I don't see the dual approach as a "solution" to a "problem"

Most of the time I highlight and middle-click: BAM!

When I need to cut or overwrite then I do it with the copy-n-paste method.

They work fine in parallel. No problems.

It rocks incredibly well, and when I have to use, say, Windows, I'm always pleased to find apps like PuTTY which make an effort to support the superior method of copy-on-select/paste-on-middle-click.

There's nothing "wrong" with making life easier for users.

Or are you just bad-mouthing one ancient piece of software that nobody is ever forced to use any more? I mean, xterm has so many, uh, quirks that it seems silly for anyone to only complain about one! :)

-danny

From 92.24.4.157 at 2011-05-05 06:09:22:

I think having copy-cut-copy-paste instead of copy-target-paste is a worthwhile exchange for the simplicity of copying by highlighting instead of highlighting and picking copy from (usually the middle of) a menu. Copying is the most common act, so surely it's right to make it the simplest act?

(It's all well and good putting "Please remember to sign your comment" but how? Nothing about signatures on the DWikiText page.)

By cks at 2011-05-05 12:20:32:

I don't feel that having two models is necessarily bad. This entry was about why xterm's approach is both 'non-standard' and cannot be the only model of cut & paste your system uses unless you are willing to have a relatively limited cut & paste model. The xterm model works very efficiently in its problem domain, which is a good thing for people who use xterm (or similar things) a lot.

(One of the reasons that I use xterm instead of some of the other options I have is precisely because xterm has this more convenient copy & paste system. The 'standard' copy & paste approach is annoyingly slower if you use it a lot.)

Having two models of cut & paste in your system does have consequences, such as needing two different internal systems to support them, but that's just a small matter of programming and can be handwaved away.

(I should clarify the 'sign your comment' note. There's no specific support for signatures here, so that just means 'put your name on the comment in some appropriate way'.)

From 97.107.130.220 at 2011-05-05 19:38:16:

What continues to confound me is why you keep bringing up xterm. The middle-click selection paste gesture works in all of X11.

The only way in which I can image xterm deserving specific mention is if it emulated pasting by sending the selection to the running console program as keyboard input at a time when other graphical terminal emulators did not. But that doesn’t make the selection paste gesture specific to it.

Aristotle Pagaltzis

By cks at 2011-05-05 21:57:05:

I call it the xterm model because I think of it as originating with xterm (I'm not certain if it did, but I suspect so) and I most frequently use it with xterm (and other terminal programs that are emulating it). Likely this is because I don't have much cause to use cut & paste outside of xterm in my environment.

(One of my three most common editors uses the 'standard' cut & paste model with additional awkwardness, one runs in xterm, and the third is GNU Emacs and I try not to think too much about how GNU Emacs interacts with X cut & paste in general.)

Written on 04 May 2011.
« The importance of xterm for X Windows
Thinking about when not disabling iSCSI's InitialR2T matters »

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

Last modified: Wed May 4 01:38:37 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.