"Steven T. Hatton" <hattons@globalsymmetry.com> writes:

I believe I've read about this somewhere, but I honestly do not understand what is going on with X copy buffers. If, for example, I go to KPDF and select text, then select copy to clipboard. When I subsequently go to Emacs (recent CVS) and attempt to paste using Shift+Insert, the most recent text I put into the Emacs killring is pasted into the buffer. Sometimes using the middle mouse button works for pasting external text into Emacs, but not in this case. Emacs is not the only app that behaves in an unexpected way when trying to copy and paste between apps. For example, if I take what I copied from KPDF and paste it into a Kate edit buffer, select it, then middle click in the Emacs buffer the text is inserted into the Emacs buffer.

Mozilla also seems to act differently than many other apps. In particular, the location field does not copy and paste as expected.

Is there a way to explain this behavior in a general way?

From the emacs info page node: Using the Clipboard

As well as the primary and secondary selection types, X supports a "clipboard" selection type which is used by some applications, particularly under OpenWindows and Gnome. The command `M-x menu-bar-enable-clipboard' makes the `Cut', `Paste' and `Copy' menu items, as well as the keys of the same names, all use the clipboard. You can customize the option `x-select-enable-clipboard' to make the Emacs yank functions consult the clipboard before the primary selection, and to make the kill functions to store in the clipboard as well as the primary selection. Otherwise they do not access the clipboard at all. Using the clipboard is the default on MS-Windows, unlike most systems. [end quote] You might also want to look into the X specification -- from the glossary: Selection A selection can be thought of as an indirect property with dynamic type. That is, rather than having the property stored in the X server, it is maintained by some client (the owner). A selection is global and is thought of as belonging to the user and being maintained by clients, rather than being private to a particular window subhierarchy or a particular set of clients. When a client asks for the contents of a selection, it specifies a selection target type, which can be used to control the transmitted representation of the contents. For example, if the selection is ``the last thing the user clicked on,'' and that is currently an image, then the target type might specify whether the contents of the image should be sent in XY format or Z format. The target type can also be used to control the class of contents transmitted; for example, asking for the ``looks'' (fonts, line spacing, indentation, and so forth) of a paragraph selection, rather than the text of the paragraph. The target type can also be used for other purposes. The protocol does not constrain the semantics. [end quote]

From chapter 16 on cut buffers:

Xlib provides functions to manipulate cut buffers, a very simple form of cut-and-paste inter-client communication. Selections are a much more powerful and useful mechanism for interchanging data between clients (see section 4.5) and generally should be used instead of cut buffers. Cut buffers are implemented as properties on the first root window of the display. The buffers can only contain text, in the STRING encoding. The text encoding is not changed by Xlib when fetching or storing. Eight buffers are provided and can be accessed as a ring or as explicit buffers (numbered 0 through 7). [end quote] Hope this helps.