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

[David De La Harpe Golden <david@harpegolden.net>]

On 24/03/12 11:10, Chong Yidong wrote:

> Why not just extend the Bug#6872 approach to handle-select-window too?
>

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.

So, you say, "then why not just add other-window too with the same 
approach?" Well, maybe, but then how many more need to be added after 
that?  That's what I was getting at when I previously remarked 
"enumerating all potential window-switching commands is probably not 
viable.".   Or maybe it is, though I guess in principle users could also 
define arbitrary new commands that called select-window (not sure many 
would. Maybe there could be an extensible select-inhibit-commands-list, 
and users who do such things could be told to push their command onto it...)


* there is probably an approach that can allow both behaviours as a 
switchable user customization, in case you think the selection yielded 
via the keyboard recipe is "right"...