--- Begin Message ---
|
Subject: |
Emacs thinks the background-mode is "dark" on Windows, when registry key HKEY_CURRENT_USER\Control Panel\Colors is empty |
|
Date: |
Sun, 12 Apr 2009 19:41:50 +0200 |
|
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.21) Gecko/20090302 Thunderbird/2.0.0.21 Mnenhy/0.7.5.0 |
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
One one particular Windows system I have the effect that Emacs started
up with black text on white background, but the links were cyan (as if
the background was dark).
(frame-parameter nil 'background-mode) returned 'dark.
After a bit of investigation, I noticed that the registry key
HKEY_CURRENT_USER\Control Panel\Colors
did not have any values assigned. I don't know how this can happen, but
it seems that Windows copes very well with that, I never had any
incorrectly displayed program before.
The WINAPI call GetSysColor(5) still returns 0xFFFFFF, as expected, so
the background is drawn in white.
As a workaround, I changed one of the system colors in control panel, so
that Windows rewrote all the Colors keys in the registry. Now Emacs
looks fine. (This bug report text is from before the change, so you
still see the original error messages below).
In GNU Emacs 22.2.1 (i386-mingw-nt5.1.2600)
of 2008-03-26 on RELEASE
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: DEU
locale-coding-system: cp1252
default-enable-multibyte-characters: t
Major mode: Fundamental
Minor modes in effect:
encoded-kbd-mode: t
tooltip-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
blink-cursor-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
auto-compression-mode: t
line-number-mode: t
Recent input:
M-x r e p o r t - e m <tab> <return>
Recent messages:
Unable to load color "SystemWindowText"
Unable to load color "SystemWindow"
Unable to load color "SystemWindowText"
Unable to load color "SystemWindow" [2 times]
Unable to load color "SystemWindowText"
Unable to load color "SystemWindow"
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done
Unable to load color "SystemWindowText"
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#2969: Emacs thinks the background-mode is "dark" on Windows, when registry key HKEY_CURRENT_USER\Control Panel\Colors is empty |
|
Date: |
Tue, 14 Apr 2009 00:23:32 +0800 |
|
User-agent: |
Thunderbird 2.0.0.21 (Windows/20090302) |
Michael Schierl wrote:
After a bit of investigation, I noticed that the registry key
HKEY_CURRENT_USER\Control Panel\Colors
did not have any values assigned. I don't know how this can happen, but
it seems that Windows copes very well with that, I never had any
incorrectly displayed program before.
The WINAPI call GetSysColor(5) still returns 0xFFFFFF, as expected, so
the background is drawn in white.
Thank you for the report.
Emacs does not use GetSysColor, as to do so would require hardcoding
system color names rather than reading them from the registry as it does
now. White is used as a fallback, because it is the default background
color for w32 frames.
I have changed frame-set-background-mode to take this into account
instead of falling through to the default of dark when non-existent
colors are specified.
--- End Message ---