Re: mouse-autoselect-window raises frames

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>>> I started to see frames raised while I was just moving my mouse.
>>>> Placing `debug-on-entry' on `raise-frame' showed the problem to be:
>>>> 
>>>> Debugger entered--entering a function:
>>>> * raise-frame(#<frame cast.v8 0x8eba878>)
>>>> select-frame-set-input-focus(#<frame cast.v8 0x8eba878>)
>>>> handle-select-window((select-window (#<window 14 on cast.v8>)))
>>>> call-interactively(handle-select-window nil nil)
>>>> 
>>>> I think the problem is that handle-select-window shouldn't call
>>>> select-frame-set-input-focus.  It should maybe call x-focus-frame instead.
>>> Would that really be less embarassing?
>> I'm not sure I understand what you mean.

> I thought you were embarassed by seeing frames raised and wanted to know
> whether you find just focussing frames less embarassing.

The way I've usually heard "embarrassing" used, is to mean "something of
which you're ashamed".  I guess you use it here more like "annoying"?

>>> What are the values of `mouse-autoselect-window' and `focus-follows-mouse'
>>> on your system?
>> Both, but that's not relevant: handle-select-window should never call
>> "raise-frame".

> It calls `select-frame-set-input-focus' and the latter raises the frame.

Right, which is why it shouldn't call select-frame-set-input-focus.

> If you think it shouldn't, let's change `select-frame-set-input-focus'
> to do exactly what its name says and look what happens.

The docstring of select-frame-set-input-focus says pretty clearly that it
raises the frame, so it's probably better to leave it unchanged.

> (note that `x-focus-frame' is not available on Windows installs)

Are you saying that under w32, you used select-frame + raise-frame (the
only thing select-frame-set-input-focus does in this case) as a substitute
for x-focus-frame?

> I changed the behavior of mouse-autoselection because people started to
> complain about modelines getting highlighted on frames that didn't get
> the focus.  When debugging this I found out that I couldn't schedule a
> select_window event without also producing a switch_frame event.  Hence
> I had to deal somehow with selected frames that did not get the focus.

Yes, I loosely followed that thread.

> If you don't want the new behavior you currently can switch-off mouse
> autoselection or set `focus-follows-mouse' to nil.

I do want mouse autoselection.  And changing focus-follows-mouse has no
effect w.r.t this problem.  The problem is very simple: select-window events
(currently) are only generated by mouse movement and Emacs should *never*
call raise-frame in response to a mouse-movement (except when asked very
specifically, such as when the frame is marked auto-raise).

> Inherently,
> `focus-follows-mouse' should be able to distinguish window management
> policies that shift input focus to another frame when the mouse enters
> it and policies that addditionally raise the frame whenever the mouse
> enters it.  Hence, we could raise the frame in `handle-select-window'
> iff `focus-follows-mouse' eqs some value 'raise and x-focus the frame
> otherwise (I'm afraid the latter won't make any difference on Windows).
> Otherwise, we could consider a new variable `mouse-autoselect-frame' to
> customize the behavior of this.

If the window-manager wants to raise the window in order to give it focus,
that's "OK" (it would piss me off, but that's why I don't use such a window
manager).  But it's not OK for Emacs to do that.


        Stefan