Re: address@hidden: 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                         
    address@hidden                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc