From: Eli Zaretskii <eliz@gnu.org>
To: Juanma Barranquero <lekktu@gmail.com>
Cc: 9722@debbugs.gnu.org
Subject: bug#9722: list-colors-duplicates does not exclude enough colors on Windows
Date: Mon, 17 Oct 2011 19:15:22 +0200 [thread overview]
Message-ID: <837h43wndh.fsf@gnu.org> (raw)
In-Reply-To: <CAAeL0SQZxN1FvLf15T0H4N6TQSA3+JhJwGp87UzqRhf_qHgygg@mail.gmail.com>
> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 17 Oct 2011 18:55:05 +0200
> Cc: 9722@debbugs.gnu.org
>
> I believe that w32-default-color-map should be declared obsolete, to
> be turned into an internal-only function in some future
> release. There's no real point to have it exposed to elisp, other
> than using it in list-colors-duplicates.
Perhaps so, but it's a separate issue.
> > I think it
> > would be cleaner to have a separate (much shorter) list of colors that
> > should not be removed even if their RGB values are identical to other
> > colors already present in the list produced by defined-colors.
>
> We can add that list, but currently, only colors named System.* are in
> that category. Checking for "^System" or populating that list are both
> very ad hoc fixes for a very specific Windows problem.
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.
> Pros:
> - The new list could be expanded by the user (if exposed to elisp as a
> list and not a function)
> - It does not depend on the reserved colors all being called System.*
>
> Contras:
> - It does not remove the need for w32_color_map /
> Fw32_default_color_map, because these have another use (default color
> list in case etc/rgb.txt is not found).
> - It adds a new function or variable and a bit of complexity, for what
> is just filtering out a few colors.
If you feel that the cons outweigh the pros, go ahead and commit your
patch.
next prev parent reply other threads:[~2011-10-17 17:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-10 22:49 bug#9722: list-colors-duplicates does not exclude enough colors on Windows Juanma Barranquero
2011-10-11 6:01 ` Eli Zaretskii
2011-10-11 11:24 ` Juanma Barranquero
2011-10-11 19:39 ` Eli Zaretskii
2011-10-11 20:54 ` Juanma Barranquero
2011-10-17 12:00 ` Juanma Barranquero
2011-10-17 16:41 ` Eli Zaretskii
2011-10-17 16:55 ` Juanma Barranquero
2011-10-17 17:15 ` Eli Zaretskii [this message]
2011-10-18 14:50 ` Juanma Barranquero
[not found] ` <83obxeuwa8.fsf@gnu.org>
[not found] ` <CAAeL0SRRkqY2r6QwASsb1JVdeSfTd9UDz3RY5QTx-PHME2iZsQ@mail.gmail.com>
[not found] ` <83k482ut21.fsf@gnu.org>
2011-10-18 19:25 ` Juanma Barranquero
2011-10-18 21:01 ` Eli Zaretskii
2011-10-24 19:29 ` Juanma Barranquero
2011-10-19 8:20 ` Juri Linkov
2011-10-19 8:36 ` Eli Zaretskii
2011-10-19 8:57 ` Juanma Barranquero
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=837h43wndh.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=9722@debbugs.gnu.org \
--cc=lekktu@gmail.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.