From: Greg Stark <gsstark@mit.edu>
Cc: bug-gnu-emacs@gnu.org
Subject: Re: Frames getting raised all the time
Date: 26 Mar 2003 23:17:46 -0500 [thread overview]
Message-ID: <87el4tl9xx.fsf@stark.dyndns.tv> (raw)
In-Reply-To: <E18yO5t-0007WA-00@fencepost.gnu.org>
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
next prev parent reply other threads:[~2003-03-27 4:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-26 6:09 Frames getting raised all the time Gregory Stark
2003-03-27 3:30 ` Richard Stallman
2003-03-27 4:17 ` Greg Stark [this message]
[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=87el4tl9xx.fsf@stark.dyndns.tv \
--to=gsstark@mit.edu \
--cc=bug-gnu-emacs@gnu.org \
/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).