bug#6774: Cut and paste with C-w/mouse-2 not working?

[Kenichi Handa <handa@m17n.org>]

In article <83iq3ovwv0.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > > But that would mean setting the selection each time the user does a
> > > C-w or M-w or any other action that pushes text on the kill ring,
> > > won't it?
> > 
> > Isn't that what Emacs has been doing for the last 10 years?

> Not as far as I know.  Maybe I was living in some pipe dream, but I
> always thought the actual copying happened only when some other
> application actually requests the selection.

The following is my current understanding about Emacs 23 and
the earlier.

C-w or M-w leads to call of interprogram-cut-function which
is usually bound to x-select-text.  On X, it does rather
complicated things.

At first, it copies the data string to CUT_BUFFER0.  Each
window of X can have properties and CUT_BUFFER0 is one of
them.  So, the data is transferred from Emacs to X server,
but it's not the inter-client copying.  This is a semi-heavy
process.

Next, if x-select-enable-primary is non-nil (the default is
t), Emacs declares to own PRIMARY selection.  In this case,
the data string is not copied but just saved in the internal
list Vselection_alist.  This is a light process.  The saved
data is transferred to another client later when requested.

At last, if x-select-enable-clipboard is non-nil (the
default is nil), Emacs declares to own CLIPBOARD selection.
The treatment of the data string is the same as above,
i.e. not copied.  But!, if a clipboard client is also
running (it seems that is the default on Ubuntu), as soon as
Emacs owns CLIPBOARD selection, it requests to get CLIPBOARD
selection data from Emacs, and the data is transferred from
Emacs to the clipboard client.  This is the inter-client
copying, and a heavy process.

So, Emacs had been doing some kind of copying on each C-w
and M-w, but the default setting avoided the heaviest process.

---
Kenichi Handa
handa@m17n.org