Frames getting raised all the time

[Gregory Stark]

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