Re: [simon.marshall@bogus.example.com: mouse-autoselect-window ne eds a delay]

Re: [simon.marshall@bogus.example.com: mouse-autoselect-window ne eds a delay]

[Marshall, Simon]

> I have focus-follows-mouse together with raise-on-focus in my window
> manager and mouse-autoselect-window in Emacs, with zero delay in both
> cases, and have never had a problem.

If you have split windows and the lower window selected, how do you move the
mouse from the lower window to the menu or tool bar without window selection
moving to the upper window?

(I can only achieve this by moving out of the Emacs frame and then into the
Emacs frame at the Emacs menu or tool bar.  And that is much easier if my WM
implements a delay for WM focus-follows-mouse, otherwise WM raise-on-focus
would cause any other window behind the Emacs frame to be raised above the
Emacs frame immediately!)

> Indeed, I love the current
> configuration.  It is much easier and more efficent for me than any
> alternative.

What alternative do you mean (other than not having
mouse-autoselect-window)?

Simon.

(I am not on the emacs-devel list, so please make any reply to me also.)

Re: [simon.marshall@bogus.example.com: mouse-autoselect-window ne eds a delay]

[Robert J. Chassell]

   If you have split windows and the lower window selected, how do you move the
   mouse from the lower window to the menu or tool bar without window selection
   moving to the upper window?

Well, I do not have a tool bar (that is the one with icons, right?  I
have turned it off.  But I do have the bar with text, which I have
always called the menu bar.  I test it occasionally.)  I just did what
I normally do when using my menu bar:  I take my hands off the
keyboard, grab the mouse, move the mouse cursor from the lower window
over the upper window to the menu bar.

As I move from the lower window to the menu bar the mouse cursor goes
over the upper window; that is the most direct route.  That action
selects the upper window (no delay) and the upper window's menu bar is
activated.

I just changed my lower window to contain a buffer with a very
different purpose from the upper window.  That way is uses a very
different library than the upper window and has different menus on the
menu bar.  To get to the menu bar required moving the mouse cursor
outside of Emacs.  I have never done that before.  (If I were to go to
the menu bar in every day use, I would first `C-x 1'
(delete-other-windows-quietly).  That action would be more efficient.)

Moving the mouse cursor outside of Emacs rather than `C-x 1'
(delete-other-windows-quietly) is clearly inefficent.  But then, so is
any action with the menu bar since it means taking your fingers off
the keyboard for an irrelevant reason.

   (I can only achieve this by moving out of the Emacs frame and then into the
   Emacs frame at the Emacs menu or tool bar.  And that is much easier if my WM
   implements a delay for WM focus-follows-mouse, otherwise WM raise-on-focus
   would cause any other window behind the Emacs frame to be raised above the
   Emacs frame immediately!)

That is true: if you take your hands off the keyboard, grab the mouse,
move the mouse cursor over another Emacs window to a bar, and if you
do not `C-x 1' (delete-other-windows-quietly), and you do not use
auto-raise much elsewhere, then to keep your first window you need a
delay.

It seems very unlikely that anyone would act so inefficently once they
learn to be efficient, but people are strange.  I see no reason not to
permit such inefficiency, but the default should be `immediate
auto-raise' and a presumption that the user is trying to use his or
her life well.  Otherwise, the Emacs developers would be highly
insulting.

   > Indeed, I love the current
   > configuration.  It is much easier and more efficent for me than any
   > alternative.

   What alternative do you mean ... ?

The example I gave, which I just suffered.  This is
focus-follows-mouse without raise-on-focus.  That caused trouble when
I went from an Emacs frame to an xterm frame.  No auto-raise.  (I am
pretty sure that in my original message, I used the word `windows' in
the original meaning.  My apologies.  For both an instance of Emacs in
X and an xterm, I meant what is now called a frame.  I do not know how
to produce a second window in an Xterm frame; for me, in this case,
the old language works fine.  For an xterm, I mean one frame with one
window in it.)

Without a X mouse cursor that autoselects an Emacs window, as in a
virtual console without a mouse, I have to switch to the window with
the keyboard.  I remember having to do that in instances of Emacs in X
before mouse cursor autoselection became possible in X frames or maybe
I clicked the mouse cursor in order to move point.  I cannot remember
which, only that the situation required irrelevant action on my part.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: [simon.marshall@bogus.example.com: mouse-autoselect-window ne eds a delay]

[Marshall, Simon]

>    If you have split windows and the lower window selected, how do you
move the
>    mouse from the lower window to the menu or tool bar without window
selection
>    moving to the upper window?

> [...]

> I just changed my lower window to contain a buffer with a very
> different purpose from the upper window.  That way is uses a very
> different library than the upper window and has different menus on the
> menu bar.  To get to the menu bar required moving the mouse cursor
> outside of Emacs.  I have never done that before.  (If I were to go to
> the menu bar in every day use, I would first `C-x 1'
> (delete-other-windows-quietly).  That action would be more efficient.)

I don't have a problem with you using Emacs how you want to.  But, as you
state, your usage of the menu bar is to test it not to use it per se.

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

Anyway, I would find it quite obscure and "inefficient" (to use your word)
to have to do C-x 1 in the window before I used the menu bar.  I would
rather Emacs not require my usage to be different for a command invoked via
a key vs via the menu or tool bar.  And the result of C-x 1 would be
different from what I had wanted.

> Moving the mouse cursor outside of Emacs rather than `C-x 1'
> (delete-other-windows-quietly) is clearly inefficent.  But then, so is
> any action with the menu bar since it means taking your fingers off
> the keyboard for an irrelevant reason.

I think this belongs to a different discussion, not in response to a bug
report!

>    (I can only achieve this by moving out of the Emacs frame and then into
the
>    Emacs frame at the Emacs menu or tool bar.  And that is much easier if
my WM
>    implements a delay for WM focus-follows-mouse, otherwise WM
raise-on-focus
>    would cause any other window behind the Emacs frame to be raised above
the
>    Emacs frame immediately!)

> That is true: if you take your hands off the keyboard, grab the mouse,
> move the mouse cursor over another Emacs window to a bar, and if you
> do not `C-x 1' (delete-other-windows-quietly), and you do not use
> auto-raise much elsewhere, then to keep your first window you need a
> delay.

> It seems very unlikely that anyone would act so inefficently once they
> learn to be efficient, but people are strange.  I see no reason not to
> permit such inefficiency, but the default should be `immediate
> auto-raise' and a presumption that the user is trying to use his or
> her life well.  Otherwise, the Emacs developers would be highly
> insulting.

Are you seriously suggesting that I am inefficient and/or strange?

Re: [simon.marshall@bogus.example.com: mouse-autoselect-window ne eds a delay]

[Stefan Monnier]

> 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