[Top][All Lists]
[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: |
Sun, 30 Sep 2007 10:47:37 +0200 |
User-agent: |
Mozilla Thunderbird 1.0 (Windows/20041206) |
> I it tried under Gnome and Window Maker, with and without focus
> follows mouse in the window manager, with f-f-m nil and t, and m-a-w
> nil, t, and 0.1. Results:
>
> f-f-m
> m-a-w nil t
> nil ok ok
> t ok 1
> 0.1 ok 2
>
>
> 1) Works fine with focus follows mouse in the window manager. With a
> click-to-focus window manager, then moving to another frame selects it.
That's the inherent deficiency of Emacs generating a switch-frame event
when there's a SELECT_WINDOW_EVENT. Whatever I do to ignore the latter
the former still gets in the way. It was also the reason for moving
`focus-follows-mouse' to C level. Now I can blame the user for not
setting this correctly - I'll have to state that in the doc-string of
`focus-follows-mouse', obviously.
> 2) Works fine with focus follows mouse in the window manager. With a
> click-to-focus window manager, then moving to another frame exhibits
> the old erroneous behaviour: the mode-line changes to active, but the
> frame is not selected.
The same. For an integer (positive or negative) I have to schedule a
SELECT_WINDOW_EVENT because I must assume that the window-manager
supports a focus follows mouse policy.
> It could well be argued that these two cases are not important,
> because focus-follows-mouse has the wrong setting (does not match the
> window manager policy).
That was the driving idea. Alternatively I would have had to introduce
another variable like `mouse-autoselect-frame'.
> HTH.
Yes, it's the expected behavior. Could you, with m-a-w 1.0 and f-f-m t
and focus follows mouse in the window manager confirm that the following
DTRT: You have two frames A and B. A has two windows 1 and 2, where 1
is active and has the mouse cursor in it. Move the mouse to frame B to
select it. Now move the mouse to window 2 on frame A. Does it get
selected? Before, Emacs consumed 99% CPU here because it got trapped in
the for (;;) loop of kbd_buffer_get_event with an unread select-window
event (you should be able to reproduce this with the scenario above and
without my patch applied).
Another issue is whether Emacs should be able to focus a frame but _not_
raise it simultaneously. I use auto-raise window-management. Hence,
Emacs policy and that of my window manager coincide. AFAIK, many focus
follows mouse users prefer a focus-only policy which clashes with the
current behavior. Fixing this is beyond Emacs 22, though. Moreover,
we'd have to decide first how a switch-frame event issued by a
focus-only window-manager could inhibit Emacs raising the frame.
Thanks a lot for testing.
- Re: mouse-autoselect-window, (continued)
- RE: mouse-autoselect-window, Drew Adams, 2007/09/18
- Re: mouse-autoselect-window, martin rudalics, 2007/09/18
- RE: mouse-autoselect-window, Drew Adams, 2007/09/18
- Re: mouse-autoselect-window, martin rudalics, 2007/09/18
- RE: mouse-autoselect-window, Drew Adams, 2007/09/18
- Re: mouse-autoselect-window, Stephen Berman, 2007/09/18
- Re: mouse-autoselect-window, martin rudalics, 2007/09/28
- Re: mouse-autoselect-window, Glenn Morris, 2007/09/29
- Re: mouse-autoselect-window,
martin rudalics <=
- Re: mouse-autoselect-window, Glenn Morris, 2007/09/30
- Re: mouse-autoselect-window, Jason Rumney, 2007/09/18
- RE: mouse-autoselect-window, Drew Adams, 2007/09/18
- Re: mouse-autoselect-window, Jason Rumney, 2007/09/18
- RE: mouse-autoselect-window, Drew Adams, 2007/09/18
- Re: mouse-autoselect-window, Eli Zaretskii, 2007/09/19
Re: mouse-autoselect-window, Eli Zaretskii, 2007/09/05