GNU bug report logs - #16619
24.3.50; REGRESSION: transparent *Completions* now

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16619 in the body.
You can then email your comments to 16619 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; REGRESSION: transparent *Completions* now
Date: Sat, 1 Feb 2014 15:11:50 -0800 (PST)

This is with my setup, admittedly.  But it is a regression introduced
by vanilla Emacs: simply changing to this build from a build from a
week earlier (2014-01-23).

The effect: Now my *Completions* buffer is completely illegible
because it is transparent/weak/faded.  I even use a special-display
frame for *Completions*, for which I define the background as
"LavenderBlush2".  Nevertheless, the frame is transparent.
Everything about it is transparent: background, foreground, title bar,
everything.  This effect makes *Completions* completely useless and
unusable.

I tried to take a screenshot to show you what I see, but the
*Completions* frame does not even show up at all for the screenshot
software.  I.e., even though I can (barely) make out by eye that there
is a *Completions* frame there, when I create a screenshot covering
that area it does not show up at all in the screenshot.

I cannot use this build at all, unfortunately.

(I thought we were in a feature freeze.)



In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2014-01-30 on ODIEONE
Bzr revision: 116210 eliz <at> gnu.org-20140130174248-vkzvius7e4zlouce
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

Message #8 received at 16619 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: Drew Adams <drew.adams <at> oracle.com>, 16619 <at> debbugs.gnu.org
Subject: Re: bug#16619: 24.3.50; REGRESSION: transparent *Completions* now
Date: Sat, 01 Feb 2014 15:38:58 -0800

On 02/01/2014 03:11 PM, Drew Adams wrote:
> This is with my setup, admittedly.  But it is a regression introduced
> by vanilla Emacs: simply changing to this build from a build from a
> week earlier (2014-01-23).
>
> The effect: Now my *Completions* buffer is completely illegible
> because it is transparent/weak/faded.  I even use a special-display
> frame for *Completions*, for which I define the background as
> "LavenderBlush2".  Nevertheless, the frame is transparent.
> Everything about it is transparent: background, foreground, title bar,
> everything.  This effect makes *Completions* completely useless and
> unusable.

What happens if you set frame-alpha-lower-limit to 100?

> I tried to take a screenshot to show you what I see, but the
> *Completions* frame does not even show up at all for the screenshot
> software.  I.e., even though I can (barely) make out by eye that there
> is a *Completions* frame there, when I create a screenshot covering
> that area it does not show up at all in the screenshot.
>
> I cannot use this build at all, unfortunately.
>
> (I thought we were in a feature freeze.)

I don't think anyone made this change deliberately. Can you try bisecting?

Message #11 received at 16619 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 16619 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#16619: 24.3.50; REGRESSION: transparent *Completions* now
Date: Sun, 2 Feb 2014 00:46:50 +0100

On Sun, Feb 2, 2014 at 12:38 AM, Daniel Colascione <dancol <at> dancol.org> wrote:

> I don't think anyone made this change deliberately. Can you try bisecting?

Drew doesn't build Emacs, and we cannot bisect without a precise
recipe for the bug.

Anyway, these are the relevant commits between his previous binary and
the newest one:

116210: Eli Zaretskii 2014-01-30 Revert last commit in mouse.el.
116209: Andreas Schwab 2014-01-30 Don't ignore SIGPROF in subprocesses
116208: martin rudalics 2014-01-30 In mouse-drag-line obey
window-resize-pixelwise (Bug#16594).
116207: Glenn Morris 2014-01-30 Auto-commit of loaddefs files.
116206: Glenn Morris 2014-01-29 * etc/NEWS: ElDoc related edit.
116205: Glenn Morris 2014-01-29 * lisp/simple.el (eval-expression): Doc fix.
116204: Glenn Morris 2014-01-29 Replace refs to obsolete alias
`turn-on-eldoc-mode' with `eldoc-mode'
116203: Stefan Monnier 2014-01-29 * eieio-opt.el (eieio-help-generic):
Fix last change.
116202: Stefan Monnier 2014-01-29 * lisp/emacs-lisp/eieio-opt.el
(eieio-help-generic): Don't assume `generic'
116201: Xue Fuqiao 2014-01-30 * doc/misc/sem-user.texi (Include
paths): Fix a Texinfo command.
116200: Glenn Morris 2014-01-29 * lisp/help.el
(help-for-help-internal): Add "P" to text.
116199: Paul Eggert 2014-01-29 * xmenu.c (create_and_show_popup_menu):
Port comment to C89.
116198: Eli Zaretskii 2014-01-29 Fix printing empty Lisp strings.
116197: Eli Zaretskii 2014-01-29 src/indent.c (current_column_1):
Correct commentary.
116196: Eli Zaretskii 2014-01-29 Fix bug #16576 with PRINTCHARFUN that
conses output a lot.
116195: K. Handa 2014-01-29 [merge] Fix bug#16286 by the different way
than revno:116158 to preserve the code detection behavior of 24.3.
116194: martin rudalics 2014-01-29 In x_set_tool_bar_lines of w32fns.c
don't clear area on frames that are not visible.
116193: Glenn Morris 2014-01-29 * etc/NEWS: Don't use a separate
section for single entries
116192: Glenn Morris 2014-01-29 * lisp/hippie-exp.el: Header comment changes.
116191: Glenn Morris 2014-01-29 Some doc for cycle-spacing
116190: Jan D. 2014-01-29 * xmenu.c (create_and_show_popup_menu):
Handle case when no key
116189: martin rudalics 2014-01-28 Fix Fwindow_text_pixel_size and
fit-frame-to-buffer.
116188: Dmitry Antipov 2014-01-28 * xfaces.c (free_frame_faces): Adjust comment.
116187: Luke Lee 2014-01-28 Aggregate hideif parser enhancements for a
complete supporting of C/C++
116186: Dmitry Antipov 2014-01-28 * terminal.c
(initial_free_frame_resources): New function.
116185: Glenn Morris 2014-01-27 Tweak previous
fill-single-char-nobreak-p doc change
116184: Glenn Morris 2014-01-27 Doc for fill-single-char-nobreak-p
116183: Glenn Morris 2014-01-27 * doc/emacs/indent.texi: Fix typo in previous
116182: Glenn Morris 2014-01-27 * doc/emacs/indent.texi (Tab Stops):
Updates for new tab-stop behavior.
116181: Glenn Morris 2014-01-27 Some doc related to tab-stops
116180: Glenn Morris 2014-01-27 * lisp/vc/pcvs.el
(cvs-append-to-ignore): Add compatibility alias.
116179: Glenn Morris 2014-01-27 * etc/NEWS: Small edits
116178: Paul Eggert 2014-01-27 Spelling fix.
116177: Glenn Morris 2014-01-27 * etc/NEWS: Tiny edits.
116176: Glenn Morris 2014-01-27 * lisp/dired.el
(dired-hide-details-mode): Don't autoload it,
116175: Glenn Morris 2014-01-27 Small doc updates for CUA and dired
116174: Glenn Morris 2014-01-27 * etc/NEWS: Small calc edits.
116173: Michael Albinus 2014-01-27 * automated/file-notify-tests.el
(file-notify--deftest-remote):
116172: Reuben Thomas 2014-01-27 * whitespace.el
(whitespace-enable-predicate): fix sense of comment.
116171: Paul Eggert 2014-01-26 * lread.c (oblookup): Fix comment to match code.
116170: Glenn Morris 2014-01-26 * doc/emacs/buffers.texi (List
Buffers): Tiny edit.
116169: Glenn Morris 2014-01-26 Doc, comment, etc updates for
increased use of locate-user-emacs-file
116168: Glenn Morris 2014-01-26 * etc/TODO: Addition.
116167: Paul Eggert 2014-01-26 * data.c (Fstring_to_number): Document
results if unparsable.
116166: Michael Albinus 2014-01-26 * file-notify-tests.el
(file-notify-test02-events): Let it fail in the
116165: Michael Albinus 2014-01-26 * automated/file-notify-tests.el
(file-notify-test02-events):
116164: Jan D. 2014-01-26 * xterm.c (x_focus_changed): Check for non-X
terminal-frame
116163: Glenn Morris 2014-01-25 Doc updates for opascal.el
116162: Paul Eggert 2014-01-25 When decoding, prefer ptrdiff_t to int
for buffer positions etc.
116161: Glenn Morris 2014-01-25 * doc/emacs/misc.texi (Sorting): Add
findex for reverse-region.
116160: Glenn Morris 2014-01-25 Some doc for delete-duplicate-lines
116159: Juanma Barranquero 2014-01-26 Fix ChangeLog typos.
116158: Paul Eggert 2014-01-25 Fix crash with insert-file-contents and
misdecoded text.
116157: Rüdiger Sonderfeld 2014-01-25 Link to info manual in `defgroup'.
116156: Leo Liu 2014-01-26 * progmodes/flymake.el
(flymake-make-overlay): No rear advance.
116155: martin rudalics 2014-01-25 Fix handling of face attributes in
Fx_create_frame (Bug#16529).
116154: Fabrice Popineau 2014-01-25 Fix bug #16517 with display change
on MS-Windows while in full-screen mode.
116153: Eli Zaretskii 2014-01-25 Fix bug #16479 with client
connections while TTY menu is open.
116152: Xue Fuqiao 2014-01-25 * doc/misc/cc-mode.texi (Minor Modes): Minor fix.
116151: Stefan Monnier 2014-01-24 * src/eval.c (Fsignal): Fix `debug'
handling to match 2013-10-03 change.
116150: Xue Fuqiao 2014-01-25 Typo fix.
116149: Adam Sjogren 2014-01-24 * net/shr.el (shr-tag-img): Prefer the
title over the alt text.
116148: David Engster 2014-01-24 Fix references in EIEIO documentation.
116147: Paul Eggert 2014-01-24 Fix bool-vector-count-population bug on MinGW64.
116146: Paul Eggert 2014-01-24 Remove stray ".".
116145: Paul Eggert 2014-01-24 Spelling fix.
116144: Bastien Guerry 2014-01-24 * editfns.c (Fconstrain_to_field):
Fix typo in docstring.
116143: Glenn Morris 2014-01-23 * etc/NEWS: Fix typos
116142: Glenn Morris 2014-01-23 * etc/NEWS.21: lesstif.org domain is
defunct, use sourceforge site.
116141: Glenn Morris 2014-01-23 * etc/NEWS: Small edits.
116140: Glenn Morris 2014-01-23 Misc small doc updates
116139: Glenn Morris 2014-01-23 Misc small doc updates
116138: Juanma Barranquero 2014-01-24 * net/eww.el
(eww-download-callback): Fix reference to eww-download-directory.
116137: Juanma Barranquero 2014-01-24 Silence byte-compiler warning.
116136: Glenn Morris 2014-01-23 Doc updates for with-demoted-errors
116135: Glenn Morris 2014-01-23 * doc/misc/emacs-mime.texi
(time-date): Use float-time.
116134: Dmitry Antipov 2014-01-24 * xdisp.c (reseat_1,
Fcurrent_bidi_paragraph_direction): Avoid
116133: Glenn Morris 2014-01-23 * doc/lispref/files.texi (File Locks):
Every platform supports locking now.
116132: Glenn Morris 2014-01-23 * doc/emacs/files.texi (Interlocking): Copyedit.
116131: Paul Eggert 2014-01-23 Document trunk bzr 116113 better.
116130: Paul Eggert 2014-01-23 Minor cleanup of previous change.

Message #14 received at 16619 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: 16619 <at> debbugs.gnu.org
Subject: RE: bug#16619: 24.3.50; REGRESSION: transparent *Completions* now
Date: Sat, 1 Feb 2014 15:57:58 -0800 (PST)

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.

Message #17 received at 16619 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Daniel Colascione <dancol <at> dancol.org>, 16619 <at> debbugs.gnu.org
Subject: RE: bug#16619: 24.3.50; REGRESSION: transparent *Completions* now
Date: Sat, 1 Feb 2014 16:06:00 -0800 (PST)

> What happens if you set frame-alpha-lower-limit to 100?

Yes, that fixes the problem.  Thank you, Daniel!  That gives
me a temporary workaround.

But I hope that is not the ultimate answer, and that you mean
that as something more than a workaround (I doubt that you do).
IOW, I don't think I should have to set this to 100.

I'm not familiar with this variable, but it seems to affect
all frames wrt frame parameter `alpha'.  I do not want to be
limited to not having frames of different opacity.  (No, I do
not currently use frames that are semi-transparent.  But I do
not want to be gratuitously prevented from doing so.)

> I don't think anyone made this change deliberately.

I don't suppose so either.  But I'm not sure what new features
that have been allowed might have been tweaked lately to make
them "work" better and which fix might have broken other things.
IOW, I have no idea what the cause is.  To me, this is just a
regression, regardless of the source.

Message #20 received at 16619 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: Drew Adams <drew.adams <at> oracle.com>, 16619 <at> debbugs.gnu.org
Subject: Re: bug#16619: 24.3.50; REGRESSION: transparent *Completions* now
Date: Sat, 01 Feb 2014 16:09:44 -0800

On 02/01/2014 04:06 PM, Drew Adams wrote:
>> What happens if you set frame-alpha-lower-limit to 100?
>
> Yes, that fixes the problem.  Thank you, Daniel!  That gives
> me a temporary workaround.
>
> But I hope that is not the ultimate answer, and that you mean
> that as something more than a workaround (I doubt that you do).
> IOW, I don't think I should have to set this to 100.
>

Indeed. I wanted to rule out problems below the normal frame parameter 
control mechanism (e.g., triggering odd display driver bugs).

> I'm not familiar with this variable, but it seems to affect
> all frames wrt frame parameter `alpha'.  I do not want to be
> limited to not having frames of different opacity.  (No, I do
> not currently use frames that are semi-transparent.  But I do
> not want to be gratuitously prevented from doing so.)
>
>> I don't think anyone made this change deliberately.
>
> I don't suppose so either.  But I'm not sure what new features
> that have been allowed might have been tweaked lately to make
> them "work" better and which fix might have broken other things.
> IOW, I have no idea what the cause is.  To me, this is just a
> regression, regardless of the source.

Yep, it's a regression. Looking at the change list, it's still not clear 
to me what causes it, and I haven't tried to repro yet. It'd be helpful 
if you could come up with a minimum configuration delta (relative to 
emacs -Q) that triggers the issue.

Message #23 received at 16619 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Daniel Colascione <dancol <at> dancol.org>, 16619 <at> debbugs.gnu.org
Subject: RE: bug#16619: 24.3.50; REGRESSION: transparent *Completions* now
Date: Sat, 1 Feb 2014 20:01:58 -0800 (PST)

> Yep, it's a regression. Looking at the change list, it's still not
> clear to me what causes it, and I haven't tried to repro yet. It'd be
> helpful if you could come up with a minimum configuration delta
> (relative to emacs -Q) that triggers the issue.

OK, here is a pretty minimal recipe to repro from emacs -Q.

Use this as your startup command:
runemacs.exe -Q -l "onetest.el" -f "1on1-emacs"

And put this in file onetest.el:

----------------8<-----------------
(provide 'oneonone)
(require 'oneonone)

(defvar 1on1-minibuffer-frame-alist
  (list
   (cons 'font "-*-Lucida Console-normal-r-*-*-14-*-*-*-c-*-iso8859-1"
         ;; If use this instead then the problem goes away.
         ;; "-Misc-Fixed-Medium-R-Normal--15-*-*-*-C-90-ISO8859-1"
         )
   (cons 'height 2)
   (cons 'minibuffer 'only)))

(defun 1on1-emacs ()
  ""
  (interactive)
  (setq default-frame-alist (list (cons 'minibuffer nil)))
  (setq pop-up-frames  t)
  (setq minibuffer-frame-alist 1on1-minibuffer-frame-alist)
  (make-frame 1on1-minibuffer-frame-alist)
  (setq minibuffer-auto-raise t)
  (setq w32-grab-focus-on-raise nil))
----------------8<-----------------

After starting Emacs, do `M-x forw TAB'.  The *Completions*
frame is transparent.

And if you change the font, per the comment, then the bug
goes away.  This is on MS Windows, where I have font Lucida
Console installed.

Message #26 received at 16619 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 16619 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>,
 Daniel Colascione <dancol <at> dancol.org>
Subject: Re: bug#16619: 24.3.50; REGRESSION: transparent *Completions* now
Date: Sun, 2 Feb 2014 07:39:31 +0100

On Sun, Feb 2, 2014 at 5:01 AM, Drew Adams <drew.adams <at> oracle.com> wrote:

> OK, here is a pretty minimal recipe to repro from emacs -Q.

Thanks.

Bisecting says the offending commit is this one:

revno: 116155
committer: martin rudalics <rudalics <at> gmx.at>
branch nick: trunk
timestamp: Sat 2014-01-25 15:39:49 +0100
message:
  Fix handling of face attributes in Fx_create_frame (Bug#16529).

  * w32fns.c (Fx_create_frame): Don't inhibit running Lisp code
  too early.  Again run change_frame_size before assigning menu-
  and tool-bar-lines.

Message #29 received at 16619 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 16619 <at> debbugs.gnu.org, Daniel Colascione <dancol <at> dancol.org>
Subject: Re: bug#16619: 24.3.50; REGRESSION: transparent *Completions* now
Date: Sun, 02 Feb 2014 14:19:11 +0100

> OK, here is a pretty minimal recipe to repro from emacs -Q.
>
> Use this as your startup command:
> runemacs.exe -Q -l "onetest.el" -f "1on1-emacs"
>
> And put this in file onetest.el:
>
> ----------------8<-----------------
> (provide 'oneonone)
> (require 'oneonone)
>
> (defvar 1on1-minibuffer-frame-alist
>   (list
>    (cons 'font "-*-Lucida Console-normal-r-*-*-14-*-*-*-c-*-iso8859-1"
>          ;; If use this instead then the problem goes away.
>          ;; "-Misc-Fixed-Medium-R-Normal--15-*-*-*-C-90-ISO8859-1"
>          )
>    (cons 'height 2)
>    (cons 'minibuffer 'only)))
>
> (defun 1on1-emacs ()
>   ""
>   (interactive)
>   (setq default-frame-alist (list (cons 'minibuffer nil)))
>   (setq pop-up-frames  t)
>   (setq minibuffer-frame-alist 1on1-minibuffer-frame-alist)
>   (make-frame 1on1-minibuffer-frame-alist)
>   (setq minibuffer-auto-raise t)
>   (setq w32-grab-focus-on-raise nil))
> ----------------8<-----------------
>
> After starting Emacs, do `M-x forw TAB'.  The *Completions*
> frame is transparent.
>
> And if you change the font, per the comment, then the bug
> goes away.  This is on MS Windows, where I have font Lucida
> Console installed.

Thanks for the excellent recipe.  I checked in a fix for this in
revision#116242.

I'm afraid that I haven't understood the processing of frame parameters
yet.  All I can do is fixing problems by trial and error.  This
particular bug crept in when I tried to fix Bug#16529.  And Bug#16529
was a consequence of attempting to fix Bug#16051. So if someone wanted
to have a look into this ...

martin

Message #32 received at 16619 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 16619 <at> debbugs.gnu.org, Daniel Colascione <dancol <at> dancol.org>,
 Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#16619: 24.3.50; REGRESSION: transparent *Completions* now
Date: Sun, 02 Feb 2014 14:19:18 +0100

> Bisecting says the offending commit is this one:
> 
> revno: 116155
> committer: martin rudalics <rudalics <at> gmx.at>
> branch nick: trunk
> timestamp: Sat 2014-01-25 15:39:49 +0100
> message:
>   Fix handling of face attributes in Fx_create_frame (Bug#16529).
> 
>   * w32fns.c (Fx_create_frame): Don't inhibit running Lisp code
>   too early.  Again run change_frame_size before assigning menu-
>   and tool-bar-lines.

Thanks for bisecting.

martin

Message #35 received at 16619 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 16619 <at> debbugs.gnu.org, Daniel Colascione <dancol <at> dancol.org>
Subject: RE: bug#16619: 24.3.50; REGRESSION: transparent *Completions* now
Date: Sun, 2 Feb 2014 07:41:15 -0800 (PST)

> I checked in a fix for this in revision#116242.
> 
> I'm afraid that I haven't understood the processing of frame
> parameters yet.  All I can do is fixing problems by trial and
> error.

Thanks for working on this, Martin.  Perhaps you do not
understand this stuff completely yet, but you no doubt still
understand it better than most of us.  And you keep working on
(hard) fixes.

Message #38 received at 16619 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 16619 <at> debbugs.gnu.org
Subject: RE: bug#16619: 24.3.50; REGRESSION: transparent *Completions* now
Date: Sun, 2 Feb 2014 08:04:14 -0800 (PST)

I just picked up a binary from Juanma (thx) and checked.
I confirm that this bug is fixed.  I'll close it.  Thx.

Message #47 received at 16619 <at> debbugs.gnu.org (full text, mbox):

From: Alan Schmitt <alan.schmitt <at> polytechnique.org>
To: 16619 <at> debbugs.gnu.org
Subject: 24.4.1; REGRESSION: transparent *Completions*
Date: Wed, 26 Nov 2014 22:33:56 +0100

Hello,

I'm seeing the same problem that Drew was having, on an OS X version of
emacs (compiled from https://github.com/railwaycat/emacs-mac-port). Here
is the adapted recipe to reproduce it.

Create a file ~/tmp/initone.el with the following

--8<---------------cut here---------------start------------->8---
(defvar 1on1-minibuffer-frame-alist
  (list
   (cons 'font "Monaco-12")
   (cons 'height 2)
   (cons 'minibuffer 'only)))

(defun 1on1-emacs ()
  ""
  (interactive)
  (setq default-frame-alist (list (cons 'minibuffer nil)))
  (setq pop-up-frames  t)
  (setq minibuffer-frame-alist 1on1-minibuffer-frame-alist)
  (make-frame 1on1-minibuffer-frame-alist)
  (setq minibuffer-auto-raise t))
--8<---------------cut here---------------end--------------->8---

Launch emacs with the following command:

open -n /Applications/Emacs.app --args -Q -l ~/tmp/initone.el -f "1on1-emacs"

After starting Emacs, do `M-x forw TAB TAB'.  The *Completions* frame is
transparent.

Things work again if I set frame-alpha-lower-limit to 100.

As the fix for Drew's issue was in w32fns.c, I suspect similar code is
broken in OS X.

Best,

Alan

Message #50 received at 16619 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Alan Schmitt <alan.schmitt <at> polytechnique.org>
Cc: 16619 <at> debbugs.gnu.org
Subject: Re: bug#16619: 24.4.1; REGRESSION: transparent *Completions*
Date: Wed, 26 Nov 2014 16:52:42 -0500

Alan Schmitt wrote:

> emacs (compiled from https://github.com/railwaycat/emacs-mac-port).

Please note the README on that site:

       If you find a bug, then please try to reproduce it with some
       official builds such as X11 or NS (Cocoa). If it turns out to be
       specific to the Mac port, then please report it to
       mituharu+bug-gnu-emacs-mac <at> math.s.chiba-u.ac.jp. Otherwise (i.e.,
       it is also reproducible with official ones), report it using M-x
       report-emacs-bug USING THE OFFICIAL BUILD as such.

(I don't think this makes it terribly clear that what is on that site is
not GNU Emacs. GNU Emacs already has a Mac port, but the "Emacs Mac
Port" is not it.)

Message #53 received at 16619 <at> debbugs.gnu.org (full text, mbox):

From: Alan Schmitt <alan.schmitt <at> polytechnique.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 16619 <at> debbugs.gnu.org
Subject: Re: bug#16619: 24.4.1; REGRESSION: transparent *Completions*
Date: Thu, 27 Nov 2014 08:56:51 +0100

[Message part 1 (text/plain, inline)]

On 2014-11-26 16:52, Glenn Morris <rgm <at> gnu.org> writes:

> Alan Schmitt wrote:
>
>> emacs (compiled from https://github.com/railwaycat/emacs-mac-port).
>
> Please note the README on that site:
>
>        If you find a bug, then please try to reproduce it with some
>        official builds such as X11 or NS (Cocoa). If it turns out to be
>        specific to the Mac port, then please report it to
>        mituharu+bug-gnu-emacs-mac <at> math.s.chiba-u.ac.jp. Otherwise (i.e.,
>        it is also reproducible with official ones), report it using M-x
>        report-emacs-bug USING THE OFFICIAL BUILD as such.
>
> (I don't think this makes it terribly clear that what is on that site is
> not GNU Emacs. GNU Emacs already has a Mac port, but the "Emacs Mac
> Port" is not it.)

Thank you for your reply. I did not know that that port was not GNU
Emacs.

I cannot reproduce the problem with the emacs from
http://emacsformacosx.com (is that one GNU Emacs?) so I guess it's an
issue with Yamamoto Mitsuharu's Mac port. I've reported a bug there.

Thanks,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.