Re: Frames getting raised all the time

[Greg Stark <gsstark@mit.edu>]

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