weird interaction between save-interprogram-paste-before-kill & mouse-autoselect-window

weird interaction between save-interprogram-paste-before-kill & mouse-autoselect-window

[Sam Steingold]

after I updated emacs this morning, I observe the following ugliness:
emacs -q
q (remove splash screen)
C-x 2 (get two windows)
evaluate in *scratch*:
(setq save-interprogram-paste-before-kill t
       mouse-autoselect-window -0.1)
now, select a word in one window with a mouse1 double-click, let it be the word 
"first".
then select a word (say, "second") in the second window also with mouse1 double 
click.
now, move the mouse back to the first window and observe that the word "second" 
no longer looks selected, while the word "first" no looks selected.
now click mouse2 (inside the first window) - "first" is inserted in the first 
window, not "second" (which was the last word I selected with the mouse!

mouse paste completely broken

[Sam Steingold]

the situation is much worse than I first thought.

emacs -q
q (remove splash screen)
C-x 5 2 (create a new frame)
now you should see two frames: "*scratch*" and "*Messages*"
select word "buffer" in "*scratch*" with double-mouse-1
and paste it with mouse2 in "*Messages*".
So far so good.
now select "information" in "*Messages*" (again, double mouse1)
and paste it (again, mouse2)  in "*scratch*".
instead of "information", the word "buffer" appears in "*scratch*".
i.e., it looks like each frame has its own notion of x selection
pastable with mouse2

I have set my window manager to focus follows mouse.

this is linux/gnome, emacs bzr tip from Monday.

Sam Steingold wrote:
> after I updated emacs this morning, I observe the following ugliness:
> emacs -q
> q (remove splash screen)
> C-x 2 (get two windows)
> evaluate in *scratch*:
> (setq save-interprogram-paste-before-kill t
>       mouse-autoselect-window -0.1)
> now, select a word in one window with a mouse1 double-click, let it be 
> the word "first".
> then select a word (say, "second") in the second window also with mouse1 
> double click.
> now, move the mouse back to the first window and observe that the word 
> "second" no longer looks selected, while the word "first" no looks 
> selected.
> now click mouse2 (inside the first window) - "first" is inserted in the 
> first window, not "second" (which was the last word I selected with the 
> mouse!
> 
> 
> 

Re: mouse paste completely broken

[David De La Harpe Golden]

On 27/07/10 21:59, Sam Steingold wrote:
> the situation is much worse than I first thought.

Emacs kill/yank default interactions with x11 selections on the 
development trunk (not the stable branch) were recently changed to [try 
to] act like recent x11 apps.  So, there are both genuine bugs being 
shaken out and intentional behavioural differences to deal with***.

... But there are definitely real problems switching frames/windows with 
active regions, what you describe is wrong, certainly from a usefulness 
perspective and after accounting for any intentional differences.

A (yes, stupid) workaround is to left click once in window X after 
selecting text in that window X before middle clicking in the other 
window Y.

I for one do intend to look at this and various issues on the various 
gui platforms (x11/ns/w32) in the area that have been made painfully 
obvious by the defaults changes, but as usual I don't have much time 
until this weekend (it is a long weekend...).

Note that I can replicate similar issues in emacs 23.2, really:

emacs -Q
C-x 3
shift-select "is for notes" in LHS *scratch*. It is highlighted.
C-x o to RHS *scratch*

Everything from the start of "is for notes" to the end of the buffer is 
highlighted, because that's where the point was in the other window, and 
select-window is "naive" (it just warps to the point saved in the the 
window).

A fix for select-active-regions somewhat similar to the zero-length 
regions fix proposed approach should certainly be possible - really we 
don't want to propagate the active region of a newly switched-to-window 
until it "really" changes anew post-restoration.

*** In the meantime, if you just want things the way they were, please 
note only defaults were changed, reversion to previous behaviour is 
fairly straightforward.  Right now, applying the settings below will do 
that (unless you used the menu bar cut/copy/paste, in which case they 
need to be rebound too):

1. customize group killing:

x-select-enable-clipboard nil  ; t on w32.
x-select-enable-primary t      ;
select-active-regions nil

2. customize group mouse:
mouse-drag-copy-region t

3. rebind:

(global-set-key [mouse-2] 'mouse-yank-at-click)

Re: mouse paste completely broken

[Stephen Berman]

On Wed, 28 Jul 2010 00:44:34 +0100 David De La Harpe Golden <david@harpegolden.net> wrote:

[...]
> Note that I can replicate similar issues in emacs 23.2, really:
>
> emacs -Q
> C-x 3
> shift-select "is for notes" in LHS *scratch*. It is highlighted.
> C-x o to RHS *scratch*
>
> Everything from the start of "is for notes" to the end of the buffer is
> highlighted, because that's where the point was in the other window, and
> select-window is "naive" (it just warps to the point saved in the the window).
>
> A fix for select-active-regions somewhat similar to the zero-length regions
> fix proposed approach should certainly be possible - really we don't want to
> propagate the active region of a newly switched-to-window until it "really"
> changes anew post-restoration.

I would be very happy if someone would fix this; I reported it as
bug#6316 but that has gotten no feedback yet.

Steve Berman

Re: mouse paste completely broken

[David De La Harpe Golden]

On 28/07/10 11:03, Stephen Berman wrote:
> On Wed, 28 Jul 2010 00:44:34 +0100 David De La Harpe Golden<david@harpegolden.net>  wrote:
>>
>> A fix for select-active-regions somewhat similar to the zero-length regions
>> fix proposed approach should certainly be possible - really we don't want to
>> propagate the active region of a newly switched-to-window until it "really"
>> changes anew post-restoration.
>
> I would be very happy if someone would fix this; I reported it as
> bug#6316 but that has gotten no feedback yet.
>
> Steve Berman
>
>

I have an experimental/throwaway branch (x11 only at present) that you 
might find works more sensibly with multiple windows / frames and 
focus-follows-mouse.

bzr branch lp:~ddlhg/emacs/selx

Trouble is it is currently terribly messy in actual implementation terms.