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

reply via email to

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