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.