From: "Robert J. Chassell" <bob@rattlesnake.com>
Subject: Re: [simon.marshall@bogus.example.com: mouse-autoselect-window ne eds a delay]
Date: Tue, 27 Jun 2006 11:19:40 +0000 (UTC) [thread overview]
Message-ID: <m1FvBbY-0004HcC@rattlesnake.com> (raw)
In-Reply-To: <81CCA6588E60BB42BE68BD029ED4826007B77677@wimex2.wim.midas-kapiti.com> (simon.marshall@misys.com)
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
next prev parent reply other threads:[~2006-06-27 11:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-27 8:30 [simon.marshall@bogus.example.com: mouse-autoselect-window ne eds a delay] Marshall, Simon
2006-06-27 11:19 ` Robert J. Chassell [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-06-28 9:11 Marshall, Simon
2006-07-04 16:15 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1FvBbY-0004HcC@rattlesnake.com \
--to=bob@rattlesnake.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).