> Why is focus-follows-mouse t by default on MS Windows? The
    > doc string says:
    >
    > "Non-nil if window system changes focus when you move the mouse.
    > You should set this variable to tell Emacs how your window manager
    > handles focus, since there is no way in general for Emacs to find out
    > automatically."
    >
    > Since MS Windows does not change focus when you move the mouse, the
    > value should be nil, by default.

    Does setting it to nil really change anything for you, on Windows?  It
    doesn't for me, AFAICS.  I always thought the Windows window manager
    cannot be controlled in this way, it sets its own focus policy.
    (FWIW, I always change the latter to follow the mouse, since I hate
    the extra click and hate even more that the window that gets focus is
    always rasied.)

    > There is plenty of platform-specific code in Emacs - it automatically
    > DTRT (as a default, at least) for several common platforms.

    But the defaults generally don't change with the platform -- that's
    that old ``platform-independent vs native-flavor'' argument again, the
    same as with ls-lisp and what's not.

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




_______________________________________________
emacs-pretest-bug mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Reply via email to