emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mouse-autoselect-window


From: martin rudalics
Subject: Re: mouse-autoselect-window
Date: Tue, 18 Sep 2007 17:34:01 +0200
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Thanks for the report !

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

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

> 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.
>
> If I have a narrow frame on top of a wider frame that has two windows, top
> and bottom, then moving the mouse from the bottom window to the top actually
> raises the other (narrow) frame, instead of just giving the focus to the top
> window.
>
> If frame 2 is directly under frame 1, then moving the mouse from window B to
> window A should focus window A, but instead it raises frame 2.
>
> Frame 1:
> .............
> |           |
> |       A   |
> |___________|
> |           |
> |       B   |
> |...........|
>
> Frame 2:
> .......
> |     |
> |     |
> |     |
> |     |
> |     |
> |.....|
>
> The behavior is actually erratic - sometimes it raises frame 2, sometimes it
> does not.

With `mouse-autoselect-window' t or a number?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]