[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.
Stefan
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: address@hidden: mouse-autoselect-window ne eds a delay],
Stefan Monnier <=