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 04:32:43 +0100

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

Previous Next

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