Re: mouse-autoselect-window

[martin rudalics <rudalics@gmx.at>]

 > Now when I make mouse-autoselect-window t and focus-follows-mouse nil,
 > then moving the mouse from one frame to another raises the latter
 > without putting it in focus.

What happens if you additionally select the frame in
`handle-select-window'?  Like

	(when mouse-autoselect-window
	  ;; Run `mouse-leave-buffer-hook' when autoselecting window.
	  (run-hooks 'mouse-leave-buffer-hook)
	  (unless focus-follows-mouse
	    ;; Make sure frame is raised when autoselecting window and
	    ;; we assume that the window manager does not autoraise the
	    ;; frame of window.
	    (select-frame (window-frame window))
	    (raise-frame (window-frame window))))

 > But in the newly raised frame the mode
 > line of the window the mouse is over still becomes active and the tool
 > bar still changes appropriately.  Do you consider this correct
 > behavior?

No.

 > Moreover, when I make mouse-autoselect-window a number, the behavior
 > is strange and rather complicated: if the unfocussed frame does not
 > have split windows, then it does not get raised when the mouse is
 > moved over it; if it does have split windows, then moving the mouse
 > over it always raises it after the delay, but only if I alternate
 > between which of the split windows I first move the mouse over -- if I
 > try moving over the same window first as I did the previous time, it
 > mostly does not get raised, but sometimes does, suggesting a timing
 > issue.  And moving the mouse back from the unfocussed to the focussed
 > frame shows the same behavior with respect to raising (i.e., only if
 > it is split and with the same alternation and timing issues).  And as
 > above, the active mode line and the tool bar change regardless of
 > focus or raised-ness.

Before `handle-select-window' gets executed the event reader schedules a
`handle-switch-frame' event which selects that frame and the previously
selected window of that frame.  I'm not yet sure how to "handle" that :-(