From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Robert J. Chassell" Newsgroups: gmane.emacs.devel Subject: Re: [simon.marshall@bogus.example.com: mouse-autoselect-window ne eds a delay] Date: Tue, 27 Jun 2006 11:19:40 +0000 (UTC) Message-ID: References: <81CCA6588E60BB42BE68BD029ED4826007B77677@wimex2.wim.midas-kapiti.com> Reply-To: bob@rattlesnake.com NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1151407216 17011 80.91.229.2 (27 Jun 2006 11:20:16 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 27 Jun 2006 11:20:16 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 27 13:20:11 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FvBbp-0006Ty-C1 for ged-emacs-devel@m.gmane.org; Tue, 27 Jun 2006 13:19:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FvBbo-0001ia-PF for ged-emacs-devel@m.gmane.org; Tue, 27 Jun 2006 07:19:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FvBbc-0001iQ-L4 for emacs-devel@gnu.org; Tue, 27 Jun 2006 07:19:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FvBbb-0001hx-9k for emacs-devel@gnu.org; Tue, 27 Jun 2006 07:19:43 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FvBbb-0001hu-2P for emacs-devel@gnu.org; Tue, 27 Jun 2006 07:19:43 -0400 Original-Received: from [69.168.108.225] (helo=rattlesnake.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FvBng-000851-Ew for emacs-devel@gnu.org; Tue, 27 Jun 2006 07:32:12 -0400 Original-Received: by rattlesnake.com via sendmail from stdin id (Debian Smail3.2.0.115) Tue, 27 Jun 2006 11:19:40 +0000 (UTC) Original-To: emacs-devel@gnu.org, "Marshall, Simon" In-reply-to: <81CCA6588E60BB42BE68BD029ED4826007B77677@wimex2.wim.midas-kapiti.com> (simon.marshall@misys.com) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:56222 Archived-At: 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