Re: focus-follows-mouse should be nil by default on MS Windows

[Eli Zaretskii]

> From: "Drew Adams" <address@hidden>
> Date: Fri, 14 Jul 2006 12:57:32 -0700
> 
>     Anyway, I cannot see any difference in behavior of, say, "C-x 5 o"
>     (which calls select-frame-set-input-focus, which Drew cited) that
>     depends on the value of this variable.  Can someone post a recipe to
>     show when this variable matters on Windows?  If not, I'm inclined to
>     document that this variable has no effect on w32 frames, and leave it
>     at that.
> 
> Documenting that would seem to be wrong, as the example I sent shows. In
> that example, if the value is nil, then the mouse position does not get set;
> if non-nil, it gets set.

Is this the example you are referring to?

> > The default value should still reflect what's appropriate for the platform,
> > even if for most purposes it's ignored by the OS. The OS might not DTRT, but
> > the behavior of Emacs code depends on the value of Emacs variables. For
> > instance, doesn't it make a difference here? I think it does.
> > 
> >   (defun select-frame-set-input-focus (frame)
> >     "Select FRAME, raise it, and set input focus, if possible."
> >     (select-frame frame)
> >     (raise-frame frame)
> >     ;; Ensure, if possible, that frame gets input focus.
> >     (cond ((eq window-system 'x) (x-focus-frame frame))
> >           ((eq window-system 'w32) (w32-focus-frame frame)))
> >     (cond (focus-follows-mouse
> >            (set-mouse-position (selected-frame)
> >                                (1- (frame-width)) 0)))))

If so, I must ask you: did you actually tried this code?  ("C-x 5 o"
calls this function, so it would suffice to try that command.)  I did
try it, with both nil and t as values of focus-follows-mouse, and I
don't see _any_ change in behavior whatsoever.  Which is what I'd
expect, since AFAIU set-mouse-position is invoked for the case where
without it the focus will stay in the original frame; this doesn't
happen on Windows, at least not for me, and the documentation of the
Windows API call invoked by w32-focus-frame seems to confirm that.

If you can show a precise recipe where this variable matters in some
way, please do.

FWIW, I think the name of the variable is misleading, to some extent:
it was introduced to overcome a difficulty with certain window
managers on X, but that difficulty is not really in the fact that
focus follows the mouse pointer; rather, the focus policy is a
_symptom_ of another problem which prevents Emacs from giving focus to
the frame as part of x-focus-frame call.  I'm not an expert on X, so
perhaps Jan or someone else could comment on what really happens on X
wrt this.