Frames getting raised all the time

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

Re: Frames getting raised all the time

[Richard Stallman]

    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.

The reason Emacs calls raise-frame when programmatically switching
frames is in case the frame it switches to is hidden by another Emacs
frame.  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.

Re: Frames getting raised all the time

[Greg Stark]

Richard Stallman <rms@gnu.org> 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

Re: Frames getting raised all the time

[Greg Stark]

"Stefan Monnier" <monnier+gnu.emacs.bug/news/@rum.cs.yale.edu> writes:

> > 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?

Hm, perhaps this is relevant? It appears there's an ICCCM way for an
application to tell the window manager that a window is "urgent" and then
leave it for the window manager to decide what to do with this information:

http://lists.eazel.com/pipermail/sawfish/2001-January/000244.html


> I actually think the problem you describe is indeed a bug and is due to
> the fact that selected_frame is temporarily changed to the minibuffer frame,
> so Emacs doesn't realize that the frame from which you hit C-x C-f
> is actually the same as the one it's trying to make visible.
> 
> The patch below fixes your simple test case.


Is this patch in 21.3 ?

-- 
greg