From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Greg Stark Newsgroups: gmane.emacs.bugs Subject: Re: Frames getting raised all the time Date: 26 Mar 2003 23:17:46 -0500 Organization: The Emacs Conspiracy; member since 1992 Sender: bug-gnu-emacs-bounces+gnu-bug-gnu-emacs=m.gmane.org@gnu.org Message-ID: <87el4tl9xx.fsf@stark.dyndns.tv> References: <87of3ymzg4.fsf@stark.dyndns.tv> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1048738727 15921 80.91.224.249 (27 Mar 2003 04:18:47 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 27 Mar 2003 04:18:47 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org Original-X-From: bug-gnu-emacs-bounces+gnu-bug-gnu-emacs=m.gmane.org@gnu.org Thu Mar 27 05:18:43 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18yOqh-00048T-00 for ; Thu, 27 Mar 2003 05:18:43 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18yOqf-0003sv-01 for gnu-bug-gnu-emacs@m.gmane.org; Wed, 26 Mar 2003 23:18:41 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18yOqA-0003Qe-00 for bug-gnu-emacs@gnu.org; Wed, 26 Mar 2003 23:18:11 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18yOq5-0003BA-00 for bug-gnu-emacs@gnu.org; Wed, 26 Mar 2003 23:18:08 -0500 Original-Received: from sabre.velocet.net ([216.138.209.205]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18yOpq-0002AV-00; Wed, 26 Mar 2003 23:17:50 -0500 Original-Received: from stark.dyndns.tv (H162.C233.tor.velocet.net [216.138.233.162]) by sabre.velocet.net (Postfix) with ESMTP id 0C76B1380D3; Wed, 26 Mar 2003 23:17:48 -0500 (EST) Original-Received: from localhost ([127.0.0.1] helo=stark.dyndns.tv ident=foobar) by stark.dyndns.tv with smtp (Exim 3.36 #1 (Debian)) id 18yOpm-0003fS-00; Wed, 26 Mar 2003 23:17:47 -0500 Original-To: rms@gnu.org In-Reply-To: Original-Lines: 61 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Original-cc: Gregory Stark X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Bug reports for GNU Emacs, the Swiss army knife of text editors List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: bug-gnu-emacs-bounces+gnu-bug-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.bugs:4659 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:4659 Richard Stallman writes: > I find it annoying how emacs insists on being the uppermost window on my > desktop. > > This is not normal Emacs behavior. I think you are saying it depends > on your init file. Please include the relevant parts of your init > file in a bug report. A .emacs with this in it is sufficient: (setq minibuffer-frame-alist '((minibuffer . only))) (setq initial-frame-alist '((minibuffer . nil))) To reproduce the problem try, for example, C-x C-f and press tab, which will bring up a *Completions* buffer in the main window raising the frame it's in. Depending on how your windowmanager places the windows you'll see different behaviour of course. In my test that main frame then obscures the minibuffer which is especially ironic since that defeats the whole logic behind doing the raise-frame. In fact because the mouse is then over the main frame it not only obscures the minibuffer confusing the user but actually steals the keyboard focus away from the minibuffer making it impossible to continue without intervening to rearrange the windows manually. bleagh. > The reason Emacs calls raise-frame when programmatically switching > frames is in case the frame it switches to is hidden by another Emacs > frame. Sure, but what if I *wanted* that frame partially hidden by something? Why would this logic not apply to every other application? Should mozilla raise it's windows every time a web page loads because there might be another mozilla window obscuring it? Should xterm raise its window every time there's terminal output in case there's another xterm on top? > It has been doing this for some ten years, and you're the first person to > complain. Perhaps we can find a consensus for what Emacs should do in that > situation. But if not, you can edit Emacs and turn raise-frame into a no-op. If there isn't perhaps it should at least be configurable? There is so much that is configurable it seems hard coding this behaviour -- in C no less -- is frustrating. I already have turned raise-frame into a noop using defadvice but that doesn't catch the C calls and I'm not anxious to maintain a local build of emacs. I suspect most people just gave up on separate minibuffers, especially since they're not widely advertised. The logic makes some sense when frames are rare and you normally never leave one frame anyways. Then popping up a buffer in another frame is tantamount to creating a new window and the user expects it to be visible. I think I'm leaning to a frame-parameter that would designate the frame's propensity to be on top. I would want to set it in special-display-frame-alist but not in default-frame-alist for example. Perhaps for most people having it set in all frames makes sense, though I'm still skeptical. -- greg