Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!uakari.primate.wisc.edu!uflorida!bikini!thoth
From: thoth@reef.cis.ufl.edu (Gilligan)
Newsgroups: comp.windows.x
Subject: Re: X cutbuffer weirdness
Message-ID: <THOTH.90Sep15174242@reef.cis.ufl.edu>
Date: 15 Sep 90 21:42:42 GMT
Sender: news@uflorida.cis.ufl.EDU
Distribution: comp
Organization: Zik Zak
Lines: 59


>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;
#--------------------/