RE: mouse-autoselect-window

["Drew Adams" <drew.adams@oracle.com>]

>  > It raises the frame, but it does not give it the input focus.
>  > I had already said (on 2007-09-05) that giving focus to the
>  > frame at the cost of raising it was a possibility:
>  >
>  >
>  >>BTW, `mouse-autoselect-window' _could_ select the mouse window in MS
>  >>Windows, even on another frame, at the cost of also raising
>  >>that frame - just add `select-frame-set-input-focus' to its code.
>  >>However, I'm not sure that is a good idea.  I assume that on
>  >>GNU/Linux etc. the focus moves but the window is not raised -
>  >>that's the behavior I would prefer, anyway.
>  >
>  > I mentioned `select-frame-set-input-focus', whereas you used
>  > `raise-frame'. The effect wrt raising is the same, but your
>  > fix does not change the input focus (for me, on Windows).
>
> You're right.  But I can't use `select-frame-set-input-focus' because it
> might move the mouse pointer as well.

(I don't remember what the problem with that is.)

> Could you try with the following substitute?
>
> 	(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 and selected when autoselecting
> 	    ;; window and we assume that the window manager does not
> 	    ;; autoraise the frame of window.
> 	    (select-frame frame)
> 	    (raise-frame frame)
> 	    ;; Ensure, if possible, that frame gets input focus.
> 	    (cond ((memq window-system '(x mac))
> 		   (x-focus-frame frame))
> 		  ((eq window-system 'w32)
> 		   (w32-focus-frame frame)))))

`frame' is unbound here. Let-bind it to (window-frame window), and it works:

(defun handle-select-window (event)
  "Handle select-window events."
  (interactive "e")
  (let ((window (posn-window (event-start event))))
    (when (and (window-live-p window)
	       ;; Don't switch if we're currently in the minibuffer.
	       ;; This tries to work around problems where the minibuffer gets
	       ;; unselected unexpectedly, and where you then have to move
	       ;; your mouse all the way down to the minibuffer to select it.
	       (not (window-minibuffer-p (selected-window)))
	       ;; Don't switch to a minibuffer window unless it's active.
	       (or (not (window-minibuffer-p window))
		   (minibuffer-window-active-p window)))
      (unless (and (numberp mouse-autoselect-window)
		   (not (zerop mouse-autoselect-window))
		   (not (eq mouse-autoselect-window-state 'select))
		   (progn
		     ;; Cancel any delayed autoselection.
		     (mouse-autoselect-window-cancel t)
		     ;; Start delayed autoselection from current mouse position
		     ;; and window.
		     (mouse-autoselect-window-start (mouse-position) window)
		     ;; Executing a command cancels delayed autoselection.
		     (add-hook
		      'pre-command-hook 'mouse-autoselect-window-cancel)))
	;; Reset state of delayed autoselection.
	(setq mouse-autoselect-window-state nil)
	(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.
            (let ((frame (window-frame window)))
              (select-frame frame)
              (raise-frame frame)
              ;; Ensure, if possible, that frame gets input focus.
              (cond ((memq window-system '(x mac))
                     (x-focus-frame frame))
                    ((eq window-system 'w32)
                     (w32-focus-frame frame))))))
	(select-window window)))))

This is an improvement, for me, but, as I said, it would be better if the
focus could be changed without necessarily raising the frame also. Those
should be two separate choices: focus & raise.

>  > I personally think that it would be OK to raise the frame too, if focus
>  > cannot be given to it otherwise, but what would really be
>  > desirable is to give focus to the frame (and window) without raising
>  > it. I don't know if that is always possible (e.g. on MS Windows), but
>  > when it is possible, it is, I think, the appropriate behavior.
>
> We could make raising optional, BTW.  You could check whether you like
> it better by removing the `raise-frame' line above.

That seems to have no effect - the frame is raised even without the call to
`raise-frame'. I presume that is because `w32-focus-frame', as its doc
string says, gives "FRAME input focus, raising to foreground if necessary".
Perhaps there is no way around this raising on Windows? Does someone know?

Again, to me, this is an improvement, even if the frame does get raised, but
if we could prevent raising (unless the user asks for that), that would be
better.

>  > Ideally, with customizable options, users would be able to control,
>  > separately, autofocus and autoraise.
>
> Agreed.
>
>  > I also see another problem with your fix (it might not be due
>  > to the fix itself, however). It doesn't always seem to raise
>  > the right frame. I don't know why. I don't know if others will
>  > see the same problem.
>
> With `mouse-autoselect-window' t or a number?

With `t'. Anyway, the code above does not seem to have this problem.