* bug#16619: 24.3.50; REGRESSION: transparent *Completions* now
@ 2014-02-01 23:11 Drew Adams
2014-02-01 23:38 ` Daniel Colascione
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Drew Adams @ 2014-02-01 23:11 UTC (permalink / raw)
To: 16619
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@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'
^ permalink raw reply [flat|nested] 15+ messages in thread* bug#16619: 24.3.50; REGRESSION: transparent *Completions* now
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-01 23:57 ` Drew Adams
2014-11-26 21:33 ` bug#16619: 24.4.1; REGRESSION: transparent *Completions* Alan Schmitt
2 siblings, 2 replies; 15+ messages in thread
From: Daniel Colascione @ 2014-02-01 23:38 UTC (permalink / raw)
To: Drew Adams, 16619
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?
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#16619: 24.3.50; REGRESSION: transparent *Completions* now
2014-02-01 23:38 ` Daniel Colascione
@ 2014-02-01 23:46 ` Juanma Barranquero
2014-02-02 0:06 ` Drew Adams
1 sibling, 0 replies; 15+ messages in thread
From: Juanma Barranquero @ 2014-02-01 23:46 UTC (permalink / raw)
To: Daniel Colascione; +Cc: 16619
On Sun, Feb 2, 2014 at 12:38 AM, Daniel Colascione <dancol@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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#16619: 24.3.50; REGRESSION: transparent *Completions* now
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
1 sibling, 1 reply; 15+ messages in thread
From: Drew Adams @ 2014-02-02 0:06 UTC (permalink / raw)
To: Daniel Colascione, 16619
> 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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#16619: 24.3.50; REGRESSION: transparent *Completions* now
2014-02-02 0:06 ` Drew Adams
@ 2014-02-02 0:09 ` Daniel Colascione
2014-02-02 4:01 ` Drew Adams
0 siblings, 1 reply; 15+ messages in thread
From: Daniel Colascione @ 2014-02-02 0:09 UTC (permalink / raw)
To: Drew Adams, 16619
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#16619: 24.3.50; REGRESSION: transparent *Completions* now
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
0 siblings, 2 replies; 15+ messages in thread
From: Drew Adams @ 2014-02-02 4:01 UTC (permalink / raw)
To: Daniel Colascione, 16619
> 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.
^ permalink raw reply [flat|nested] 15+ messages in thread* bug#16619: 24.3.50; REGRESSION: transparent *Completions* now
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
1 sibling, 1 reply; 15+ messages in thread
From: Juanma Barranquero @ 2014-02-02 6:39 UTC (permalink / raw)
To: Drew Adams; +Cc: 16619
On Sun, Feb 2, 2014 at 5:01 AM, Drew Adams <drew.adams@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@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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#16619: 24.3.50; REGRESSION: transparent *Completions* now
2014-02-02 6:39 ` Juanma Barranquero
@ 2014-02-02 13:19 ` martin rudalics
0 siblings, 0 replies; 15+ messages in thread
From: martin rudalics @ 2014-02-02 13:19 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 16619
> Bisecting says the offending commit is this one:
>
> revno: 116155
> committer: martin rudalics <rudalics@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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#16619: 24.3.50; REGRESSION: transparent *Completions* now
2014-02-02 4:01 ` Drew Adams
2014-02-02 6:39 ` Juanma Barranquero
@ 2014-02-02 13:19 ` martin rudalics
2014-02-02 15:41 ` Drew Adams
1 sibling, 1 reply; 15+ messages in thread
From: martin rudalics @ 2014-02-02 13:19 UTC (permalink / raw)
To: Drew Adams; +Cc: 16619
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#16619: 24.3.50; REGRESSION: transparent *Completions* now
2014-02-02 13:19 ` martin rudalics
@ 2014-02-02 15:41 ` Drew Adams
2014-02-02 16:04 ` Drew Adams
0 siblings, 1 reply; 15+ messages in thread
From: Drew Adams @ 2014-02-02 15:41 UTC (permalink / raw)
To: martin rudalics; +Cc: 16619
> 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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#16619: 24.3.50; REGRESSION: transparent *Completions* now
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:57 ` Drew Adams
2014-11-26 21:33 ` bug#16619: 24.4.1; REGRESSION: transparent *Completions* Alan Schmitt
2 siblings, 0 replies; 15+ messages in thread
From: Drew Adams @ 2014-02-01 23:57 UTC (permalink / raw)
To: 16619
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#16619: 24.4.1; REGRESSION: transparent *Completions*
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:57 ` Drew Adams
@ 2014-11-26 21:33 ` Alan Schmitt
2014-11-26 21:52 ` Glenn Morris
2 siblings, 1 reply; 15+ messages in thread
From: Alan Schmitt @ 2014-11-26 21:33 UTC (permalink / raw)
To: 16619
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#16619: 24.4.1; REGRESSION: transparent *Completions*
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
0 siblings, 1 reply; 15+ messages in thread
From: Glenn Morris @ 2014-11-26 21:52 UTC (permalink / raw)
To: Alan Schmitt; +Cc: 16619
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@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.)
^ permalink raw reply [flat|nested] 15+ messages in thread* bug#16619: 24.4.1; REGRESSION: transparent *Completions*
2014-11-26 21:52 ` Glenn Morris
@ 2014-11-27 7:56 ` Alan Schmitt
0 siblings, 0 replies; 15+ messages in thread
From: Alan Schmitt @ 2014-11-27 7:56 UTC (permalink / raw)
To: Glenn Morris; +Cc: 16619
[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]
On 2014-11-26 16:52, Glenn Morris <rgm@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@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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 494 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2014-11-27 7:56 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
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).