Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!uw-beaver!zephyr.ens.tek.com!tektronix!reed!vishnu!trost From: trost@reed.edu Newsgroups: comp.unix.ultrix Subject: Re: Editor with DecWindows Message-ID: Date: 10 May 91 00:06:48 GMT References: <1991May2.150153.18386@cm.cf.ac.uk> <1991May3.123357.19598@cs.utk.edu> <1991May6.132302.11959@pronto.mh.nl> Sender: nobody@reed.UUCP Organization: Reed College Lines: 28 Return-Path: In-Reply-To: jv@mh.nl's message of 6 May 91 13:23:02 GMT In article <1991May6.132302.11959@pronto.mh.nl>, jv@mh.nl (Johan Vromans) writes: ... except that you cannot cut&paste between DECwindows applications (like DECterm) and standard X11 applications (like GNU Emacs/Epoch) since DECwindows uses a different cut/paste mechanism. Careful what you say there -- emacs is probably the one at fault there, since you can't cut and paste between emacs and, say, xterm or xedit. To be precise: There are two methods for exchanging information between X clients, cutbuffers and selections. Emacs only uses cut buffers; specifically, it writes its string out to the CUT_BUFFER0 property on "the" root window. With the other method, a client (like xterm) takes ownership of the selection (in this case, the PRIMARY selection); when someone wants the contents of the selection, xterm receives a SelectionRequest (I think) event and then is expected to put the information in a property on a window specified in the event. Then, when a standard X client like xterm is trying to "paste", the first thing it does is ask for the PRIMARY selection. If no one owns it, or if it doesn't get a reply in a "reasonable" amount of time (2 seconds or so), it gives up and uses the CUT_BUFFER0 instead. Emacs will use both when version 19 comes out (how many times have we heard *that* one? :-) ).