--- Begin Message ---
|
Subject: |
list-colors-duplicates does not exclude enough colors on Windows |
|
Date: |
Tue, 11 Oct 2011 00:49:43 +0200 |
Package: emacs
Severity: minor
On Windows, `list-colors-duplicates' matches the color name against
the output of `w32-default-color-map', to avoid conflating colors
which are RGB-equal, but semantically different, like SystemMenuText
and SystemWindowText.
Unfortunately, that makes colors not in that list different even if
they are not, in particular all the grayNN/greyNN pairs.
The following patch discards that check, and uses instead the
heuristic that the only special colors on Windows are the ones
starting with "System". That has always been the case anyway, and it's
unlikely for the user to define a non-special System* color (and if he
does, this patch will cause no harm anyway, it will just not be
considered a duplicate of other colors).
Juanma
2011-10-10 Juanma Barranquero <address@hidden>
* facemenu.el (list-colors-duplicates): On Windows, detect more
duplicates by assuming that only colors matching "^System" are
special "system colors".
=== modified file 'lisp/facemenu.el'
--- lisp/facemenu.el 2011-09-11 01:55:09 +0000
+++ lisp/facemenu.el 2011-10-10 22:39:20 +0000
@@ -639,8 +639,8 @@
(l list))
(while (cdr l)
(if (and (facemenu-color-equal (car (car l)) (car (car (cdr l))))
- (not (if (fboundp 'w32-default-color-map)
- (not (assoc (car (car l)) (w32-default-color-map))))))
+ (not (and (eq system-type 'windows-nt)
+ (string-match-p "^System" (car (car l))))))
(progn
(setcdr (car l) (cons (car (car (cdr l))) (cdr (car l))))
(setcdr l (cdr (cdr l))))
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#9722: list-colors-duplicates does not exclude enough colors on Windows |
|
Date: |
Tue, 18 Oct 2011 16:50:08 +0200 |
On Mon, Oct 17, 2011 at 19:15, Eli Zaretskii <address@hidden> wrote:
> Perhaps so, but it's a separate issue.
Obviously, it does not affect this bug. Rather, it depends on this bug
to be fixed.
> Yes, but checking for "^System.*" must be in facemenu.el, while the
> list could be on a w32-only file. Not a bug deal either way.
You still would need a way to access the list from facemenu.el,
conditional to some f?boundp or system-type check, so no net gain
there.
> If you feel that the cons outweigh the pros, go ahead and commit your
> patch.
Well, I'm not enthralled by the idea of hardcoding "^System", but I
also dislike adding a w32-specific variable that isn't likely to
change or be useful to the user.
Juanma
--- End Message ---