|
From: | David De La Harpe Golden |
Subject: | bug#8996: Set PRIMARY from last selection, not last selected window |
Date: | Sun, 25 Mar 2012 04:32:43 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0 |
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"...
[Prev in Thread] | Current Thread | [Next in Thread] |