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





reply via email to

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