Re: mouse-autoselect-window

[Jeremy Maitin-Shepard]

"Drew Adams" <address@hidden> writes:

>> > `focus-follows-mouse' has no effect in MS Windows, according to
>> > the doc and to my experience.
>> 
>> The doc is wrong, and should be changed.
>> 
>> focus-follows-mouse has the same effect on Windows as on any other
>> system. AFAICT the only effect is that when set, the mouse gets moved to
>> the newly focused frame when the focussed frame is changed
>> programatically (so that the window manager honors the focus change).
>> You can see this with ediff for example.

> 1. I'm not 100% sure I understand you. I guess you mean that if, for
> example, some code does `select-frame-set-input-focus', then the mouse
> pointer will be moved to the newly selected frame. Is that right?

> That's certainly true. But if that is the only intended effect of
> `focus-follows-mouse', then I'd say that this option should be named
> `mouse-follows-focus', not the reverse. IOW, what you describe (and what I
> see) is that _if_ the focus is changed to another frame _then_ the mouse is
> warped to that frame.

> 2. Also, people often say, rightly or wrongly, that `focus-follows-mouse' is
> useless, inappropriate, ineffective etc. for use with window managers that
> impose a click-frame-to-focus policy. If the only intended effect of
> `focus-follows-mouse' is what you say it is, then these (common) statements
> are off the mark, and whatever window manager policy one has would appear to
> be irrelevant.

The following applies to X11:

My take on `focus-follows-mouse' is that it tells Emacs that it can make
use of the hack of warping the mouse pointer in order to change the
window manager frame focus.  With a click-to-focus window manager, this
hack is not available, and consequently Emacs may be unable to change
the window manager focus.

There is not really any completely correct way for Emacs to switch to a
different frame.  Using XSetInputFocus certainly is not the correct way
at all, because (a) window managers are likely to actively prevent such
uses, since clients often misuse it, and (b) it doesn't work if the
window to which focus will be transfered is unmapped (iconified), which
may be the case if the window manager has iconified it or
"shaded/rolled" it, an action that a tiling or tabbing window manager
may do routinely.  The best way to switch focus may be to use the method
described in the Extended Window Manager Hints document, namely sending
a _NET_ACTIVE_WINDOW message.  This could perhaps be used in conjunction
with XSetInputFocus and the mouse warping hack, since not all window
managers support the _NET_ACTIVE_WINDOW message.

For MS Windows:

I believe there are standard Windows API functions that can be used to
raise or focus a particular top-level window, and consequently such
hacks as are needed for X11 are not needed for MS Windows.

-- 
Jeremy Maitin-Shepard