[Top][All Lists]

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

Re: address@hidden: mouse-autoselect-window ne eds a delay]

From: Stefan Monnier
Subject: Re: address@hidden: mouse-autoselect-window ne eds a delay]
Date: Tue, 04 Jul 2006 12:15:55 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

> OTOH, I use the menu bar if (a) I happen to be holding the mouse, (b) I
> can't remember the key binding, or (c) there isn't a key binding.  My report
> was pointing out a problem with mouse-autoselect-window when used with split
> windows and the menu or tool bar.  Given that you don't use the menu or tool
> bar, ...

I agree with you that it's a problem.  The same problem appears on Mac OS
X if you want to use focus-follows-mouse because Mac OS X's window system
uses a single menu-bar shared between all applications.  I don't know how
they solve it, but I know how X11 and w32 solve it: have each frame carry
its own menu-bar.

And that's indeed what I do here: I use C-down-mouse-3 to get the menu-bar
at point rather than having to move the mouse to the top of the frame.

Now, I agree that it only provides a workaround rather than a fix, but some
people (e.g. myself) may prefer this workaround rather than the
delayed-selection you propose.

BTW, I believe that you can implement a form of delayed-selection without
any of the heavy hacking mentioned in this thread.  Basically: change
`handle-select-window' such that it doesn't immediately selects the window
but instead fires a timer (and kills any still pending delayed-selection
timer).  Additionally to the timer, it could add a pre-command-hook so that
hitting a key forces the selection to be done immediately.  All in elisp.


reply via email to

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