[Top][All Lists]

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

bug#8996: Set PRIMARY from last selection, not last selected window

From: David De La Harpe Golden
Subject: bug#8996: Set PRIMARY from last selection, not last selected window
Date: Sun, 25 Mar 2012 14:42:14 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0

On 25/03/12 04:42, Chong Yidong wrote:
David De La Harpe Golden<address@hidden>  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"*

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).

reply via email to

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