Re: Clipboard interactions

["Jan Djärv" <jan.h.d@swipnet.se>]

Stephen J. Turnbull skrev 2010-07-13 04.06:
> Jan Djärv writes:
>
>   >  If we are talking about copy/paste of text from Emacs, Xt would not enter in
>   >  to it.  AFAIK, the only place where Motif may be involved in Emacs is
>   >  copy/paste in the file dialog.  All selection code in Emacs is plain X.
>
> Don't take the toolkit name too seriously.  What I mean is that there
> is a clipboard protocol in the ICCCM, and which does involve some
> overhead.  Doesn't Emacs conform to that protocol when copying to/
> pasting from the clipboard?  If so, it should suffer from similar
> overhead.  Our experience is that the overhead is perceptible in 1
> Mbit network environments in some conditions we don't really
> understand.  Not frequent, but frequent enough that having the option
> to turn off clipboard is useful for users who only need "drag button1
> to select, click button2 to copy".

Maybe you are thinking of the section that talks about a special clipboard 
client that always take a copy of the clipboard and retains it even if the 
program it got it from died, like the KDE Klipper.

The presence of such a client has no impact on the protocol itself, it just 
leads to a lot of transfers of data from Emacs to, for example, Klipper (I use 
Klipper below as an example, but the issues are generic).

We have seen problems with this when copying a whole buffer, i.e. lots of 
data. Klipper may also do a lot of polling to see if the clipboard changed, 
but most X servers now implement XFixes, so polling should be reduced, 
hopefully to 0.

But Klipper and its kind are totally optional (I always turn these IMHO stupid 
things off), and ICCCM says:

"A special CLIPBOARD client is not necessary. The protocol used by the cutting 
client and the pasting client is the same whether the CLIPBOARD client is 
running or not."

and

"The reasons not to run the clipboard client include:

     * Performance - Data is only transferred if it is actually required (that 
is, when some client actually wants the data).
     * Flexibility - The clipboard data may be available as more than one target."

Klipper can also be configured to collect PRIMARY, so restricting clipboard 
may be of no use.

So it should not be up to Emacs to limit itself because some of its users want 
to run a clipboard client.

	Jan D.