jwz@lucid.com (Jamie Zawinski) (09/15/90)
I've been encountering some strange interactions between GNU Emacs and the X server cutbuffer. I am using some code which transfers text from Emacs to the server cutbuffer with a form like (x-store-cut-buffer (buffer-substring ... )). This usually works - I can, for example, click middle in an Xterm and have the text pasted there. And also, the form (insert (x-get-cut-buffer)) will put the text back into emacs. But every now and then, the text seems to go to a different place - say I copy the form "FOO" from Emacs to the cut buffer; and then some time later, I copy "BAR". If I click middle in an Xterm, it pastes "FOO" instead of "BAR", although pasting it into emacs (with x-get-cut-buffer) pastes "BAR". Also, sometimes clicking in one Xterm will paste "FOO" and clicking in another will paste "BAR". It is as if one of the Xterms is deciding that it should be using a different cut buffer or something. I'm not sure exactly what is the thing between copying "FOO" and "BAR" that makes the behavior change, but I suspect it might have something to do with copying or pasting large blocks of text. Does it seem possible that something like that could cause Emacs or an Xterm to use a different cut buffer? Is there a way to examine the contents of the various server cut buffers? Any suggestions would be appreciated. Thanks, -- Jamie <jwz@lucid.com> PS: Emacs 18.55, X11R4 patchlevel 11, Sun3.
thoth@reef.cis.ufl.edu (Gilligan) (09/16/90)
>jwz@lucid.com (Jamie Zawinski) >I've been encountering some strange interactions between GNU Emacs and the X >server cutbuffer. I am using some code which transfers text from Emacs to the The problem is probably that emacs is not using the most recent ICCCM conventions for selections. I'm still fuzzy on the details myself, but basically there are two mechanisms for cut+paste. *** LESSON IN CUT+PASTE FOLLOWS *** The CUT_BUFFERs are for simple applications and can be accessed with the Xlib convenience functions XStoreBytes, XFetchBytes, XStoreBuffer, XFetchBuffers and XRotateBuffers. There are 8 cut buffers on the root window stored as data in properties (Atoms: CUT_BUFFER[0-7]). The Athena text widget uses them, but also uses the more up to date convention of Selections. Emacs uses cut buffers, but I don't think it understands the more recent conventions unless you get some other elisp that does all sorts of cut+paste magic for emacs. (Here's where I get fuzzy) Selections are managed by the server. There can be multiple selections, each associated with a different Atom, but the main one is associated with the Atom PRIMARY (surprise!). To get the value of a selection you use the Xlib function XConvertSelection with an Atom specifying which selection (usually PRIMARY), an atom specifying a target type (probably STRING), a property Atom, a Window, and a time. The client that owns the selection will convert the selection to the requested type and put it on the Window in the requested property. The selection owner will then send the requestor a SelectionNotfy event (using XSendEvent) that indicates the success or failure of the operation. (A client that asks for a BITMAP type selection when the owner has only a STRING will probably not work too well unless the owner is EXTREMELY sophisticated.) You can become the owner of a selection by using the Xlib call XSetSelectionOwner with the selection Atom (PRIMARY), a Window (for events to go to I guess) and a time. You should then check to make sure you have the selection with XGetSelectionOwner. Once you have the selection you have to service SelectionRequest events (the result of some poor slob asking for a selection) and also SelectionClear events (when someone else asserts ownership). In the ICCCM doc there's a rather large section on pushing large selections around and some stuff about other selections than the PRIMARY. There is also a list of conversion targets and their meanings (which I don't completely understand). The ICCCM doc is available for anonymous ftp from uunet in comp.sources.x/volume2/icccm. It is postscript and I don't know where the original source is. I often wish I had a text version so I could isearch through it in emacs, but you can't win them all. -- #perl -ne #/-------------------- print "a window is a terrible thing to paste -", $me; #( My name's not really Gilligan, It's Robert Forsman, without an `e' ) s/Gilligan/Robert Foresman/g; s/Foresman/Forsman/g; #--------------------/
jwz@lucid.com (Jamie Zawinski) (09/16/90)
The strange interaction between Emacs, Xterm, and the cut buffers is because most Xterm clients use selections instead of (well, superceding) cut buffers. If there is a selection around, Xterms will use that instead of the cut buffer. Emacs doesn't know about selections, but you can convince Xterm to always use the cut buffer instead of selections by adding this to you .Xdefaults: ! emacs only copies to cut buffer 0. xterm by default ! wants to paste from the PRIMARY selection XTerm*VT100.Translations: #override ~Meta <Btn2Up>: insert-selection(CUT_BUFFER0) This works under R3, and probably R4, but not R2. Thanks to Thomas Narten for the prizewinning answer. He's going on to our bonus round where the scores can really change. -- Jamie
dshr@eng.sun.COM (David Rosenthal) (09/18/90)
Someone who appears to be called Robert Foresman replied to a question about cut-buffers with a longish message explaining that he didn't really understand the relevant documentation in the ICCCM but thought that things worked roughly like this. This was an example of an unhelpful trend that is reducing the signal to noise ratio on xpert. Please, if you know where the relevant documentation is but don't fully understand it, don't write long messages putting forward your (probably incorrect) understanding. Just point people to the documentation and let them read it. Then, if they don't understand something specific, they can ask. And you won't have tempted other people to think that they understand what is going on without the need to RTFM, act on your (probably incorrect) understanding, and get themselves into trouble. The reason why the ICCCM sections on selections are "rather large" is because it is a complex subject with many pitfalls. For someone who admits that they don't understand these pitfalls to attempt to summarize the ICCCM sections in a mail message is likely to cause more problems than it solves. You will note that even though I was the editor of the ICCCM, I am not attempting to summarize the relevant sections - I would prefer people to actually read them. The second edition of the Digital Press book contains a version of the ICCCM that contains the same information as the version in PostScript on the R4 tape, but is much more readable (thanks to the efforts of the Digital Press editors). David.