mouse-autoselect-window raises frames

mouse-autoselect-window raises frames

[Stefan Monnier]

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.


        Stefan


PS: BTW, select-frame-set-input-focus has a typo in that it checks for
a window-system called `max'.  Should that be `mac' or `mac-carbon' or maybe
(fboundp 'x-focus-frame)?

Re: mouse-autoselect-window raises frames

[martin rudalics]

 > 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?  What are the values of
`mouse-autoselect-window' and `focus-follows-mouse' on your system?

Re: mouse-autoselect-window raises frames

[Stefan Monnier]

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

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


        Stefan

Re: mouse-autoselect-window raises frames

[martin rudalics]

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

 >>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.
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 (note that
`x-focus-frame' is not available on Windows installs).

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.

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

Re: mouse-autoselect-window raises frames

[martin rudalics]

> Both, but that's not relevant: handle-select-window should never call
> "raise-frame".

Maybe you're right.  Let the window manager decide whether it
wants to focus or raise the frame.  I'll take this out in two
days unless someone finds a compelling reason to keep it.

Re: mouse-autoselect-window raises frames

[Stefan Monnier]

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

Re: mouse-autoselect-window raises frames

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

How about "inconveniencing"?

-- 
David Kastrup

Re: mouse-autoselect-window raises frames

[martin rudalics]

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

Yes (although you were probably ashamed of the way Emacs behaves due to
my changes).

 >>(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?

Emacs 22 uses `w32-focus-frame' but I think Jason has changed that for
Emacs 23.  The doc-string is

w32-focus-frame is a built-in function in `src/w32fns.c'.
(w32-focus-frame frame)

Give frame input focus, raising to foreground if necessary.

Hence, the Windows substitute for `x-focus-frame' and
`select-frame-set-input-focus' both raise the frame.

 > I do want mouse autoselection.  And changing focus-follows-mouse has no
 > effect w.r.t this problem.

`focus-follows-mouse' nil should inhibit selecting and subsequently
raising another frame.  If it doesn't it's a bug.

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

The problem is that mouse movement also generates a switch-frame event
which is equally disturbing.  But I'm already convinced that there's no
reason to either focus or raise the frame in `handle-select-window'.

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

An auto-raise window-manager doesn't raise the window in order to give
it focus but simply in order to avoid changing the position of `point'
(as you would do with a mouse click) when you want to switch to a
specific window with the mouse.

Re: mouse-autoselect-window raises frames

[Stefan Monnier]

>> I do want mouse autoselection.  And changing focus-follows-mouse has no
>> effect w.r.t this problem.
> `focus-follows-mouse' nil should inhibit selecting and subsequently
> raising another frame.  If it doesn't it's a bug.

I saw the same problem with focus-follows-mouse set to nil, so I guess there
is a bug.

> The problem is that mouse movement also generates a switch-frame event
> which is equally disturbing.

Why should it be disturbing?  AFAIK all it does is `select-frame', right?

> But I'm already convinced that there's no reason to either focus or raise
> the frame in `handle-select-window'.

Great ;-)

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

> An auto-raise window-manager doesn't raise the window in order to give
> it focus but simply in order to avoid changing the position of `point'
> (as you would do with a mouse click) when you want to switch to a
> specific window with the mouse.

I was thinking of the WM raising the window not because of auto-raise but
because of click-to-focus and more generally because it wants to impose
a policy where "focus'd frame is never behind another".


        Stefan

Re: mouse-autoselect-window raises frames

[martin rudalics]

 >>`focus-follows-mouse' nil should inhibit selecting and subsequently
 >>raising another frame.  If it doesn't it's a bug.
 >
 >
 > I saw the same problem with focus-follows-mouse set to nil, so I guess there
 > is a bug.

Strange.  handle_one_xevent has

		  if (WINDOWP(window)
		      && !EQ (window, last_window)
		      && !EQ (window, selected_window)
		      && (focus_follows_mouse
			  || (EQ (XWINDOW (window)->frame,
				  XWINDOW (selected_window)->frame))))
                   {
                     inev.ie.kind = SELECT_WINDOW_EVENT;
                     inev.ie.frame_or_window = window;
                   }

How do you get a select-window event?

Re: mouse-autoselect-window raises frames

[martin rudalics]

 >>The problem is that mouse movement also generates a switch-frame event
 >>which is equally disturbing.
 >
 >
 > Why should it be disturbing?  AFAIK all it does is `select-frame', right?

Almost.  It also triggered the initial complaint, my attempts to fix
this, the present thread ...

Re: mouse-autoselect-window raises frames

[Stefan Monnier]

> Strange.  handle_one_xevent has

> 		  if (WINDOWP(window)
> 		      && !EQ (window, last_window)
> 		      && !EQ (window, selected_window)
> 		      && (focus_follows_mouse
> 			  || (EQ (XWINDOW (window)->frame,
> 				  XWINDOW (selected_window)->frame))))
>                   {
>                     inev.ie.kind = SELECT_WINDOW_EVENT;
>                     inev.ie.frame_or_window = window;
>                   }

> How do you get a select-window event?

Don't know.  I guess I got into the case where

			  || (EQ (XWINDOW (window)->frame,
				  XWINDOW (selected_window)->frame))))

-- Stefan