I came across this on, iirc, an xdg list on which I lurk: Specifications/ClipboardsWiki (http://freedesktop.org/wiki/Specifications/ClipboardsWiki)
It was useful to me in getting some idea about how the clipboard (should) work in X (and hints at the mechanisms that make it work). Below are some quotes. Perhaps some of the information will be useful to someone looking into the "anomalies" that seem to occur with the clipboard and so forth in nedit and/or when nedit is used with other applications. I don't know if I ever mentioned one of my problems: I use klipper (I don't know if that's relevant), and sometimes when copying something from nedit to some other application (or vice versa, but I don't think I see it as often in that direction), klipper and the target application "hang" for a fairly long time. By hang, I mean that the klipper "icon" in the toolbar disappears for up to 60 seconds, and during that time, I can't paste, and, for example, if I'm trying to paste into kmail, kmail is hung for that same period of time. I suspect that some of this problem is due to what they call the asynchronous approach to cut and paste in X / Linux. Iiuc, when you cut or copy something it is not immediately put in a place (I hesitate to use the word buffer, since it may have a more specific connotation in this context) from which it can be pasted. Instead, it is not until the paste occurs (or is attempted) that the text is actually "extracted" from the source document. Having written that out, maybe that's not the problem. Still, the information or the apparently new recommendations might be useful. (Or maybe it's all old stuff. ??) Anyway, some quotes (there is more stuff in the document): <quote> Application authors should follow the following guidelines to get correct behavior: * selecting but with no explicit copy should only set PRIMARY, never CLIPBOARD * middle mouse button should paste PRIMARY, never CLIPBOARD * explicit cut/copy commands (i.e. menu items, toolbar buttons) should always set CLIPBOARD to the currently-selected data (i.e. conceptually copy PRIMARY to CLIPBOARD) * explicit paste commands should paste CLIPBOARD, not PRIMARY * possibly contradicting the ICCCM, clients don't need to support SECONDARY, though if anyone can figure out what it's good for they should feel free to use it for that * cut buffers are evil; they only support ASCII, they don't work with many clients, and they require data to be copied to the X server. Therefore clients should avoid using cut buffers and use only selections. ... A remaining somewhat odd thing about X selections is that exiting the app you did a cut/copy from removes the cut/copied data from the clipboard, since the selection protocol is asynchronous and requires the source app to provide the data at paste time. The solution here would be a standardized protocol for a "clipboard daemon" so that apps could hand off their data to a daemon when they exit. Or alternatively, you can run an application such as xclipboard which constantly "harvests" clipboard selections. </quote> I presume klipper is probably similar to xclipboard in constantly "harvesting" clipboard selections, which means my suspicions about the cause of the kmail hangups may not be true. But, it would be nice to have all this stuff "just work". Randy Kramer -- NEdit Develop mailing list - [email protected] http://www.nedit.org/mailman/listinfo/develop
