From: Drew Adams <drew.adams@oracle.com>
To: 16619@debbugs.gnu.org
Subject: bug#16619: 24.3.50; REGRESSION: transparent *Completions* now
Date: Sat, 1 Feb 2014 15:57:58 -0800 (PST) [thread overview]
Message-ID: <fb2562ae-1aa7-4c6c-b01a-e206f72a6371@default> (raw)
In-Reply-To: <f493591a-9338-48eb-818e-5fb916368318@default>
It's even worse than what I reported at first.
Other special-display frames that pop up when the minibuffer is
active are also transparent. This includes frame *Pp Eval Output*
if I do `M-:' while the minibuffer is active (e.g., from `M-x').
(I have `M-:' bound in minibuffer maps to a command that essentially
does pp-eval-expression, and *Pp Eval Output* is a special-display
buffer because of `special-display-regexps'.)
And it includes frame *Backtrace* if I try to use the debugger
when the minibuffer is active.
However, I discovered something else that might help you solve
this mystery. In all cases where I get a transparent frame
popped up, the frame that was selected when I invoked a command
that used the minibuffer was an ordinary frame, not my standalone
minibuffer frame.
If I instead first select the minibuffer frame (which is useless
for normal use, but worthwhile for this experiment) and I then
invoke a command (such as `M-x') from there that activates the
minibuffer, then *Completions* is normal - not transparent.
So something in this build is acting normal only when the
standalone minibuffer frame is selected before minibuffer
activation, and popping up transparent frames when another frame
is selected before minibuffer activation.
next prev parent reply other threads:[~2014-02-01 23:57 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-01 23:11 bug#16619: 24.3.50; REGRESSION: transparent *Completions* now Drew Adams
2014-02-01 23:38 ` Daniel Colascione
2014-02-01 23:46 ` Juanma Barranquero
2014-02-02 0:06 ` Drew Adams
2014-02-02 0:09 ` Daniel Colascione
2014-02-02 4:01 ` Drew Adams
2014-02-02 6:39 ` Juanma Barranquero
2014-02-02 13:19 ` martin rudalics
2014-02-02 13:19 ` martin rudalics
2014-02-02 15:41 ` Drew Adams
2014-02-02 16:04 ` Drew Adams
2014-02-01 23:57 ` Drew Adams [this message]
2014-11-26 21:33 ` bug#16619: 24.4.1; REGRESSION: transparent *Completions* Alan Schmitt
2014-11-26 21:52 ` Glenn Morris
2014-11-27 7:56 ` Alan Schmitt
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=fb2562ae-1aa7-4c6c-b01a-e206f72a6371@default \
--to=drew.adams@oracle.com \
--cc=16619@debbugs.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).