Cut and Paste in X (idea)

Basically, there are two orthogonal and (theoretically) non-interacting clipboard systems in use on X11:

• The Macintosh-style clipboard which is the same as the clipboard on other major windowing systems, where it is set only by explicit "Cut" and "Copy" commands, and pasted with a "Paste" command. Many applications use the traditional Ctrl-X, Ctrl-C, and Ctrl-V keyboard shortcuts for these commands.
• The 'traditional' X11 clipboard which contains the most recently selected text and which is inserted on a middle-click.

As you can see, cut and paste is more complicated under the X Window System than it is under most other window systems. This is both due to the richer functionality X aims to provide and due to X's stated goal of providing mechanism, not policy. This latter factor is generally desirable since mechanism is more permanent than policy, allowing X an unbroken line of backwards compatibility from the initial release of X11 in 1987 to the present day, much longer than any other window system¹. However, differences in clipboard policy can be more annoying than differences in other parts of user interface policy, leading to many problems over X's history.

What X Provides

X provides two mechanisms for transferring text (or other data) between applications: selections and cut buffers. Cut buffers are deprecated, so in the words of jwz, "Never, ever, ever use them. Ever." Cut buffers are synchronous, meaning that the contents are transferred to the X server every time they are updated. Given that one of the models used for cut and paste under X involves updating a clipboard every time new text is selected, this has too much overhead in real-world applications. (This is particularly true for real-world applications in 1988...)

The fix for this was to implement selections in X11R1. In this case, a program merely claims the selection (by name) and then other programs can request the contents of the selection directly from the program. In addition to decreasing server overhead, it also loosens the limit on the size of the content. Three selections are defined in the ICCCM, which is the standard for communication between X clients. These are called PRIMARY, SECONDARY, and CLIPBOARD. Most of the work is done with PRIMARY and CLIPBOARD.

What We Want To Have

Two concepts of cut and paste have developed over the years. One has its roots in the original Macintosh, and the other was developed in the early days of X. Both have their merits and both are supported by most X programs. The Macintosh convention is familiar to almost all computer users, using explicit "Cut" and "Copy" commands to set the clipboard and an explicit "Paste" command to insert its contents. The original X clipboard is less intuitive but faster, where selecting text also copies it to the clipboard, and a click of the middle mouse button will paste it.

The Bad Old Days

It used to be that there was no consistent mapping from the two concepts to the actual X facilities, and furthermore no consistent set of keyboard shortcuts for the Macintosh-style clipboard. Some programs would use CLIPBOARD for the explicit Cut, Copy and Paste commands, while others would use PRIMARY. This led to situations where Cut from one app won't Paste in another, which combined with previous contents of the clipboards makes the operation seen nondeterministic.

Complicating matters is that PRIMARY was almost invariably used for the original X cut and paste operation, even if the explicit Mac-style operations also used PRIMARY. This, in itself, was a usability disaster. The Copy command doesn't actually do anything in this system. Furthermore, the Cut command can be rather destructive, in that if some text is cut, and then new text selected, the original text is lost. To 'avoid' some of these problems, elabourate and obscure clipboard history programs such as xclipboard and klipper were used to allow the user to do (simple) things like select a section of text and 'paste over' it.

The Standards Era

In 2001 and 2002, the major X11 software projects finally agreed on a standard for using the X clipboard. This was significant progress in making X cut-and-paste more consistent and usable. The explicit commands were assigned to the CLIPBOARD selection and were prohibited from modifying the PRIMARY selection. The keyboard shortcuts were also standardised on the traditional Ctrl-X, Ctrl-C, and Ctrl-V, except in programs such as Emacs and terminal emulators where there are overriding historical concerns. To the new X user, this convention is compatibile with Windows and the Mac OS, with the older and faster X-style clipboard as a 'power user' trick. This standard is followed by all GNOME and GTK+ applications, including Mozilla, KDE applications after KDE 3.0, and recent versions of Emacs and XEmacs.

That's not to say that X cut-and-paste is perfect. One wart in the design is that if a program 'controls' the clipboard when it exits, the clipboard contents are lost, since they are stored in the application rather than in the X server. Another, possibly more serious problem is the practical inability of the X clipboard to handle non-textual information. Apparently, there is a mechanism for applications to transfer arbitrary data through the clipboard, but its use is neither widespread nor standardised. It remains a promising idea for future development, though.

For the gory details, see http://www.jwz.org/doc/x-cut-and-paste.html², or the freedesktop.org clipboard standard document at http://standards.freedesktop.org/clipboards-spec/clipboards-0.1.txt .

1. A history of Unix user interface design explaining this decision can be found at http://catb.org/~esr/writings/taoup/html/ch11s02.html .
2. This web page, along with X experience in both the bad old days and these standards-compliant days, was the source for much of this writeup's raw data.