GNU bug report logs - #41544
26.3; Possible incorrect results from color-distance

Previous Next

Package: emacs;

Reported by: Simon Pugnet <simon <at> polaris64.net>

Date: Tue, 26 May 2020 16:34:01 UTC

Severity: normal

Tags: patch

Found in version 26.3

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias EngdegÄrd <mattiase <at> acm.org>
Cc: tom <at> tromey.com, simon <at> polaris64.net, 41544 <at> debbugs.gnu.org
Subject: bug#41544: 26.3; Possible incorrect results from color-distance
Date: Mon, 01 Jun 2020 19:32:39 +0300
> From: Mattias EngdegÄrd <mattiase <at> acm.org>
> Date: Sun, 31 May 2020 22:46:07 +0200
> Cc: Simon Pugnet <simon <at> polaris64.net>, 41544 <at> debbugs.gnu.org,
>         Eli Zaretskii <eliz <at> gnu.org>
> 
> Proposed patch attached. I found css-mode no worse than before (a tad better, if anything). Perhaps we need to decompress to linear components after all, but at least now there is a single place to do it.
> 
> (Should list-colors-display use color-dark-p for the text in its left column, by the way? Or is there a point in not doing so?)

Please remind me why do we want to make such deep and wide changes in
our color system?  Is that just because we have a minor bug in
color-distance?  Wouldn't it be better to just fix that one bug?

I'm worried because the way our automatic color mapping on
color-challenged TTYs works took some time to get right, and it worked
well for years.  If we want to risk rocking that particular boat som
profoundly, we had better had a very good reason, preferably several
good reasons.

Thanks.




This bug report was last modified 4 years and 304 days ago.

Previous Next


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