emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Clipboard interactions


From: Jan Djärv
Subject: Re: Clipboard interactions
Date: Tue, 13 Jul 2010 09:53:33 +0200
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1



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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]