A brief history of cut and paste in X

Here's a brief history and explanation of how cut and paste works in the X Windows system (to give it its formal name), prompted by this blog entry with the entirely reasonable gripe that selecting something in a program and then exiting the program causes the selection to disappear.

There are two separate cut and paste mechanisms in X, from two separate eras: the cut buffer and selections. The cut buffer is the older mechanism, and works by having programs store the cut data into an X property on the root window, which you can see directly with 'xprop -root CUT_BUFFER0'. (Technically there are eight or so cut buffers, but almost no one uses anything except the first one.)

The cut buffer has some limitations:

• it doesn't handle large amounts of data, because it stores things in X properties.
• it only really handles text, and text without character set information at that.
• you can only make the data available in one representation, when it may have several possible ones.

These were fine as long as the X was mostly used to run xterm and xclock (to swipe a slam from the Unix-Haters Handbook), but not so good when people started trying to do more sophisticated things. Enter selections.

Selections solve the cut buffer limitations by making the program that generated the selection hold onto the selection itself. When other programs want to paste something, they talk to the holding program directly to get a copy, and negotiate things like what format it's going to be in.

The drawback of the selection model is what Martin Krafft experienced: if the program that set up a selection goes away, so does the selection, because no one else has a copy. (In fact the creating program can make the selection go away any time it feels like, and often has to take extra steps to take a private copy just for the selection.)

As a pragmatic matter, any program that selects text should export the selection into the cut buffer and anything that can paste text in should read from the cut buffer if there's no current selection, because that avoids most of the problem. Unfortunately there has been something of a movement for ignoring the cut buffer as 'obsolete', so things like Firefox and gnome-terminal never go near it.

(A more complete technical explanation is in Jamie Zawinski's X Selections, Cut Buffers, and Kill Rings.)

Sidebar: selections and the clipboard

The clipboard is effectively a second selection; it uses the same mechanisms and also goes away when the owning program exits. What shows up in the clipboard versus what is just a plain selection depends on the application, but the general rule is that copying or selecting something explicitly will make it into the clipboard instead of a mere selection. For most purposes you can ignore the difference.

The xclipboard program keeps a copy of the clipboard contents, which can sometimes be convenient. It also makes a handy text window to scribble stuff in.

(A similar xselection program is possible, but I don't know if anyone's already written it. It might cause significantly more X traffic and CPU usage, since programs change the selection a fair bit more than they change the clipboard.)