From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Gregory Stark Newsgroups: gmane.emacs.bugs Subject: Frames getting raised all the time Date: 26 Mar 2003 01:09:15 -0500 Sender: bug-gnu-emacs-bounces+gnu-bug-gnu-emacs=m.gmane.org@gnu.org Message-ID: <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 1048659037 21017 80.91.224.249 (26 Mar 2003 06:10:37 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 26 Mar 2003 06:10:37 +0000 (UTC) Original-X-From: bug-gnu-emacs-bounces+gnu-bug-gnu-emacs=m.gmane.org@gnu.org Wed Mar 26 07:10:36 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 18y47P-0005Sj-01 for ; Wed, 26 Mar 2003 07:10:36 +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 18y46J-0004CU-00 for gnu-bug-gnu-emacs@m.gmane.org; Wed, 26 Mar 2003 01:09:27 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18y46B-0004CO-00 for bug-gnu-emacs@gnu.org; Wed, 26 Mar 2003 01:09:19 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18y46A-0004CC-00 for bug-gnu-emacs@gnu.org; Wed, 26 Mar 2003 01:09:18 -0500 Original-Received: from sabre.velocet.net ([216.138.209.205]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18y469-0004C8-00 for bug-gnu-emacs@gnu.org; Wed, 26 Mar 2003 01:09:17 -0500 Original-Received: from stark.dyndns.tv (H162.C233.tor.velocet.net [216.138.233.162]) by sabre.velocet.net (Postfix) with ESMTP id 3E08613802B; Wed, 26 Mar 2003 01:09:16 -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 18y467-0008O7-00; Wed, 26 Mar 2003 01:09:15 -0500 Original-To: bug-gnu-emacs@gnu.org Original-Lines: 78 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:4653 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:4653 In GNU Emacs 21.2.2 (i386-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2002-10-15 on raven, modified by Debian configured using `configure i386-linux --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes --with-x=yes --with-x-toolkit=athena --without-gif' I find it annoying how emacs insists on being the uppermost window on my desktop. It's the only application that insists on raising itself to the top whenever it feels it has something important to say. This is very Windows(tm)-ish behaviour and is seriously antisocial on unix desktops where the user is normally allowed to control the stacking order explicitly and applications rarely fiddle with it. I can't think of a single other application that fiddles with the stacking order like this. If you're thinking, "but it doesn't raise itself all the time for me" then you're probably not using a separate minibuffer frame. In tracking down the cause of the behaviour I've lost count of the number of raise-frame, make_frame_visible, and x_make_frame_visible invocations. But most of them are called iff the selected frame isn't the frame emacs thinks you should be looking at. This is often triggered when using a separate minibuffer frame since the selected frame is often the minibuffer frame and the event that emacs thinks is urgently important is normally displaying a new buffer in a window, which means selecting a non-minibuffer frame. I've managed to defeat many of the calls to raise-window using defadvice. and setting hooks. I think these calls should probably all be removed or at the very least wrapped in an (if let-emacs-fascistly-determine-my-window-stacking-order ...) However the worst offender is also proving the hardest to defeat. Every time I do a minibuffer-complete and emacs wants to pop up a *Completions* buffer my emacs frame raises itself above everything else. This happens extremely frequently and every time I curse under my breath at emacs. The reason minibuffer-complete raises the frame is because of the following C code. There's no way to defeat this without reimplementing all of display-buffer's logic in a display-buffer-function lisp function. That looks to be quite a hassle. What would be really nice would be if there was some way to disable all the raise-frame calls that are done spontaneously without the user requesting it. It's not normal behaviour for unix applications to raise and lower existing frames themselves. Of course the user should still be able to raise and lower frames when she wants to so my current big hammer of defadvising around raise-frame isn't a valid long-term strategy. static Lisp_Object display_buffer_1 (window) Lisp_Object window; { Lisp_Object frame = XWINDOW (window)->frame; FRAME_PTR f = XFRAME (frame); FRAME_SAMPLE_VISIBILITY (f); if (!EQ (frame, selected_frame)) { if (FRAME_ICONIFIED_P (f)) Fmake_frame_visible (frame); else if (FRAME_VISIBLE_P (f)) Fraise_frame (frame); } return window; } Recent messages: Refusing to raise frame damnit! Mark saved where search started Mark set [3 times] Auto-saving...done Mark set [2 times] call-interactively: Text is read-only [4 times] Loading emacsbug...done -- greg