bug#1765: Copy/paste inconsistent with other X apps

bug#1765: Copy/paste inconsistent with other X apps

[Ole Laursen]

Hi!

In every other recent X app I have tried, copy/pasting works the way
that the mouse selection = copy and middle click = paste is seperate
from the C-c/C-v clipboard. This fits in with the description here:

  http://www.freedesktop.org/wiki/Specifications/ClipboardsWiki
  http://www.jwz.org/doc/x-cut-and-paste.html

However, my Emacs 22.2.1 (started with emacs -Q) is confusing the two.
If I kill-ring-save "foo", select "bar" with the mouse and yank I get
"bar" instead of "foo". With the above spec, I should have gotten
"bar" only if I pressed M-w before yanking.

This is mostly annoying when pasting from another program, e.g. using
C-c to copy "foo" in the browser, then yanking the text in Emacs. If
you accidentally click the wrong place, the effort in selecting "foo"
is lost.

I think it makes sense to change the Emacs behaviour to make it a good
citizen in the free desktop. And it's arguably also more likely to
prevent loss of clips.

-- 
Ole Laursen
http://people.iola.dk/olau/

bug#1765: Copy/paste inconsistent with other X apps

[Chong Yidong]

> In every other recent X app I have tried, copy/pasting works the way
> that the mouse selection = copy and middle click = paste is seperate
> from the C-c/C-v clipboard.  I think it makes sense to change the
> Emacs behaviour to make it a good citizen in the free desktop. And
> it's arguably also more likely to prevent loss of clips.

Set x-select-enable-clipboard to t.

(We might consider making this the default after the release.  ISTR
there was a technical reason not to do this, but details elude me right
now.  Maybe it's a matter of speed?)

bug#1765: Copy/paste inconsistent with other X apps

[Sven Joachim]

On 2009-01-04 04:33 +0100, Chong Yidong wrote:

>> In every other recent X app I have tried, copy/pasting works the way
>> that the mouse selection = copy and middle click = paste is seperate
>> from the C-c/C-v clipboard.  I think it makes sense to change the
>> Emacs behaviour to make it a good citizen in the free desktop. And
>> it's arguably also more likely to prevent loss of clips.
>
> Set x-select-enable-clipboard to t.
>
> (We might consider making this the default after the release.  ISTR
> there was a technical reason not to do this, but details elude me right
> now.  Maybe it's a matter of speed?)

I don't think it's a matter of speed (I set x-select-enable-clipboard to
t long ago, and there are no noticeable delays), but rather the problems
that occur with pasting text from "legacy" applications like xterm that
only use the primary selection.  See
http://lists.gnu.org/archive/html/emacs-devel/2007-09/msg02462.html.

Note that Emacs doesn't quite DTRT no matter what the value of
x-select-enable-clipboard is.  This report in Debian's BTS sums it up
quite nicely: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416462.

Sven

bug#1765: Copy/paste inconsistent with other X apps

[Ole Laursen]

2009/1/4 Sven Joachim <svenjoac@gmx.de>:
> On 2009-01-04 04:33 +0100, Chong Yidong wrote:
>
>>> In every other recent X app I have tried, copy/pasting works the way
>>> that the mouse selection = copy and middle click = paste is seperate
>>> from the C-c/C-v clipboard.  I think it makes sense to change the
>>> Emacs behaviour to make it a good citizen in the free desktop. And
>>> it's arguably also more likely to prevent loss of clips.
>>
>> Set x-select-enable-clipboard to t.

It doesn't work, it's letting the selection overwrite the clipboard.
The behaviour we need here is that yank uses the clipboard and
kill-ring only. Never the selection.


I looked into x-win.el, and it seems this change (Dec. 25 2007) did
all the hard work:

  http://cvs.savannah.gnu.org/viewvc/emacs/lisp/term/x-win.el?root=emacs&r1=1.218&r2=1.219

So it's merely a matter of changing the two defcustoms

 (defcustom x-select-enable-clipboard nil ...)
 (defcustom x-select-enable-primary t ...)

to the reverse

 (defcustom x-select-enable-clipboard t ...)
 (defcustom x-select-enable-primary nil ...)

> I don't think it's a matter of speed (I set x-select-enable-clipboard to
> t long ago, and there are no noticeable delays), but rather the problems
> that occur with pasting text from "legacy" applications like xterm that
> only use the primary selection.  See
> http://lists.gnu.org/archive/html/emacs-devel/2007-09/msg02462.html.

But that's a problem with xterm. It only supports mouse copy/paste.
And actually, as far as I can tell, it's still working with xterm
because it's using the cut buffers that everyone seam to agree should
die but Emacs is still supporting (also with the above changes I'm
suggesting).

Regarding speed issues: other applications with much larger data sets
can use the clipboard without problems. If you read Jamie Zawinski's
account, he's arguing that it's a problem because people might have a
clipboard monitoring app that sucks in the data - but the natural
evolution of that argument is that no X apps should use the clipboard
because of performance issues. If you have a program that slows down
your desktop because it's monitoring the clipboard in a dumb way, then
either you remove that program or you fix it to be less dumb. In any
case, it's not Emacs' problem.

-- 
Ole Laursen
http://people.iola.dk/olau/

bug#1765: Copy/paste inconsistent with other X apps

[Richard M Stallman]

    However, my Emacs 22.2.1 (started with emacs -Q) is confusing the two.
    If I kill-ring-save "foo", select "bar" with the mouse and yank I get
    "bar" instead of "foo". With the above spec, I should have gotten
    "bar" only if I pressed M-w before yanking.

This is a very useful feature.  It means, for instance, that you can use
C-y in Emacs to insert text that was selected in other apps.

    This is mostly annoying when pasting from another program, e.g. using
    C-c to copy "foo" in the browser, then yanking the text in Emacs. If
    you accidentally click the wrong place, the effort in selecting "foo"
    is lost.

That is vague, and I do not follow.  What do you mean by "the wrong
place"?  In what sense is the effort "lost"?

bug#1765: Copy/paste inconsistent with other X apps

[Stefan Monnier]

> Regarding speed issues: other applications with much larger data sets
> can use the clipboard without problems. If you read Jamie Zawinski's

IIRC the speed issue had to do with the fact that in Emacs it is very
common to select the region (with the keyboard) for purposes that have
nothing to do with cut&paste.  E.g. you may select enormous amounts of
text (e.g. almost the whole buffer) just to perform a search&replace or
an undo-in-region.

If you consider "select a region with the keyboard" as meaning "copy to
clipboard", then you can end up with serious performance problems.
Even more so with remote connections, of course.

So as long as "copy to clipboard" is a separate command there shouldn't
be any problem.


        Stefan

bug#1765: Copy/paste inconsistent with other X apps

[Thomas E. Dickey]

Sven Joachim <svenjoac@gmx.de> wrote:
> I don't think it's a matter of speed (I set x-select-enable-clipboard to
> t long ago, and there are no noticeable delays), but rather the problems
> that occur with pasting text from "legacy" applications like xterm that
> only use the primary selection.  See
> http://lists.gnu.org/archive/html/emacs-devel/2007-09/msg02462.html.

The information in that url is incorrect - xterm's been configurable to
use primary or clipboard selection for the past couple of years.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

bug#1765: Copy/paste inconsistent with other X apps

[Ole Laursen]

2009/1/4 Richard M Stallman <rms@gnu.org>:
>    However, my Emacs 22.2.1 (started with emacs -Q) is confusing the two.
>    If I kill-ring-save "foo", select "bar" with the mouse and yank I get
>    "bar" instead of "foo". With the above spec, I should have gotten
>    "bar" only if I pressed M-w before yanking.
>
> This is a very useful feature.  It means, for instance, that you can use
> C-y in Emacs to insert text that was selected in other apps.

But the thing is that this goes against the defacto standard - and it
is there for good reasons. Standard paste/yank always only inserts
text that was explicitly copied to the clipboard. If you read this
short document

  http://www.freedesktop.org/wiki/Specifications/ClipboardsWiki

it's very clear on this.

The problem with not following the spec is that text selections are
used for a lot of stuff. If I patiently select a piece of text with
the mouse and press C-c, I expect to be able use that piece of text
later - even if I have selected another piece of text, or just clicked
an input field with automatic text selection.

Imagine having the kill ring filled up with random stuff every time
you press C-space and move the cursor. That's what Emacs is currently
doing with clips from other programs.

-- 
Ole Laursen
http://people.iola.dk/olau/

bug#1765: Copy/paste inconsistent with other X apps

[Ole Laursen]

2009/1/5 Stefan Monnier <monnier@iro.umontreal.ca>:
> So as long as "copy to clipboard" is a separate command there shouldn't
> be any problem.

Exactly. Nothing happens until you press M-w/C-w.

-- 
Ole Laursen
http://people.iola.dk/olau/

bug#1765: Copy/paste inconsistent with other X apps

[Ole Laursen]

Darn, this went to the wrong address.

2009/1/5 Ole Laursen <olau@hardworking.dk>:
> 2009/1/4 Richard M Stallman <rms@gnu.org>:
>>    However, my Emacs 22.2.1 (started with emacs -Q) is confusing the two.
>>    If I kill-ring-save "foo", select "bar" with the mouse and yank I get
>>    "bar" instead of "foo". With the above spec, I should have gotten
>>    "bar" only if I pressed M-w before yanking.
>>
>> This is a very useful feature.  It means, for instance, that you can use
>> C-y in Emacs to insert text that was selected in other apps.
>
> But the thing is that this goes against the defacto standard - and it
> is there for good reasons. Standard paste/yank always only inserts
> text that was explicitly copied to the clipboard. If you read this
> short document
>
>  http://www.freedesktop.org/wiki/Specifications/ClipboardsWiki
>
> it's very clear on this.
>
> The problem with not following the spec is that text selections are
> used for a lot of stuff. If I patiently select a piece of text with
> the mouse and press C-c, I expect to be able use that piece of text
> later - even if I have selected another piece of text, or just clicked
> an input field with automatic text selection.
>
> Imagine having the kill ring filled up with random stuff every time
> you press C-space and move the cursor. That's what Emacs is currently
> doing with clips from other programs.
>
> --
> Ole Laursen
> http://people.iola.dk/olau/
>



-- 
Ole Laursen
http://people.iola.dk/olau/

bug#1765: Copy/paste inconsistent with other X apps

[David De La Harpe Golden]

Please note bug #902, which patches emacs towards
X11 fd.o cut+paste compliance, provided you follow
the instructions associated with the expanded
select-active-regions docstring in the patch.

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=902

bug#1765: Copy/paste inconsistent with other X apps

[Ole Laursen]

I just got Emacs 23 on my Debian system - nice work!

However, it seems the algorithm has changed? Or maybe I just didn't
test it correctly last time. With x-select-enable-clipboard at t, you
can do the following sequence:

1. Select "foo" in Firefox, copy it with C-c.
2. Select "bar" in Firefox with the mouse.
3. Switch to Emacs and hit C-y and get "foo" as mandated by the spec (great!).

However, if you switch back to Firefox and select "apples", then
switch to Emacs and hit C-y, you now get "apples" instead of "foo"? I
tried setting x-select-enable-primary to nil, but then middle-mouse is
broken and selecting something in Emacs with the mouse doesn't put it
in primary.

I did try the suggestion in the updated docstring for
select-active-regions, but it didn't quite work, maybe because
select-active-regions was broken before the patch.

The automagic going on in the relevant function confuses me, but maybe
that's because it's written with the old behaviour in mind (no
difference between primary/clipboard) with these options being bolted
on afterwards. It appears to me that it's lacking a
dont-use-selection-when-yanking-and-kill-ring-when-inserting setting,
then the two x-select-enable-* could be left at true.

-- 
Ole Laursen
http://people.iola.dk/olau/