From: Gregory Stark <gsstark@mit.edu>
Subject: Frames getting raised all the time
Date: 26 Mar 2003 01:09:15 -0500 [thread overview]
Message-ID: <87of3ymzg4.fsf@stark.dyndns.tv> (raw)
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
next reply other threads:[~2003-03-26 6:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-26 6:09 Gregory Stark [this message]
2003-03-27 3:30 ` Frames getting raised all the time Richard Stallman
2003-03-27 4:17 ` Greg Stark
[not found] <200303271650.h2RGotNl028733@rum.cs.yale.edu>
2003-05-09 14:52 ` Greg Stark
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=87of3ymzg4.fsf@stark.dyndns.tv \
--to=gsstark@mit.edu \
/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).