GNU bug report logs - #8996
Set PRIMARY from last selection, not last selected window

Previous Next

Full log

View this message in rfc822 format

From: David De La Harpe Golden <david <at> harpegolden.net>
To: Chong Yidong <cyd <at> gnu.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 8996 <at> debbugs.gnu.org
Subject: bug#8996: Set PRIMARY from last selection, not last selected window
Date: Sun, 25 Mar 2012 14:42:14 +0100

On 25/03/12 04:42, Chong Yidong wrote:
> David De La Harpe Golden<david <at> harpegolden.net>  writes:
>
>> Well, that only catches cases that happen owing to things that trigger
>> the<select-window>  event that handle-select-window is bound to.
>>
>> But that event isn't fired when you C-x o - other-window just straight
>> calls the select-window function.  So, with your patch applied, it
>> probably fixes the visible issue in Stefan's focus-follows-mouse case,
>> but my keyboard recipe previously given still yields the "wrong"*
>> selection.
>
> OTOH, keyboard commands stealing the selection seems a little less
> problematic, because the user is specifically doing an Emacs command
> rather than just moving the mouse.  I'm not sure it's wrong for C-x o to
> get the selection if the window switched to has an active region.

Hmm, well, subjectively it did feel wrong to me, it is after all the 
context I spotted the issue in.  But I'm now presumably also influenced 
by months of using my locally munged emacs.

In terms of current practice of one of our "competitors" (loosely) that 
has fairly similar functionality, kde kate, it does _not_ appear to 
reset x11 primary to the older but still visibly highlighted region when 
you just switch between windows, even with the keyboard (of course it 
doesn't use emacs terminology for the entities in question, but 
functionally similar), it sticks to the temporal order:

launch kate, enter a new session
enter "The quick brown fox jumps over the lazy dog."
hit Ctrl-Shift-T  (split window)
select (shift-arrow keys) "fox" in window #1
hit F8 (switch window)
select (shift-arrow keys) "dog" in window #2
hit F8 (switch window)
-> current window #1 again, and has "fox" region still visibly 
highlighted (and it is again current in terms of intra-kate ops like 
overtyping it)
hit mouse-2
->  "dog" is inserted from primary.

In gvim, given modality there are probably too many differences for the 
comparison to be fair, anyway it doesn't reset primary to the older (and 
unlike emacs/kate, not visible anyway) region when you switch windows. 
Visible region highlighting apparently disappears once you exit visual 
mode, so the question of visual vs. temporal correspondence that arises 
in emacs/kate is irrelevant, temporal is the natural option. Visual mode 
seems to be exited when you switch windows to a window onto a different 
buffer, it's only maintained if both windows are onto the same buffer 
and in which case they apparently have the same visual region, so the 
same-buffer/different-window/different-visible-region case of emacs or 
kate probably can't arise (not a vim expert, mind).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.