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


Message #217 received at 41544 <at> debbugs.gnu.org (full text, mbox):

From: Mattias EngdegÄrd <mattiase <at> acm.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 41544 <at> debbugs.gnu.org
Subject: Re: bug#41544: 26.3; Possible incorrect results from color-distance
Date: Fri, 21 Aug 2020 13:32:14 +0200
[Message part 1 (text/plain, inline)]
20 aug. 2020 kl. 15.08 skrev Lars Ingebrigtsen <larsi <at> gnus.org>:

> Mattias?

I don't want to revive this discussion and consider the matter settled, but since you asked:

Suppose we add standard-colour-darkness-predicate, say, with color-dark-p being the default and (r+b+g)/3<0.6 the 'traditional' option (or the default, if you prefer). How would the effects of that choice be explained to the user?

A difference is only visible when:

1. a face sensitive to the background mode is used (many standard faces are), and
2. a background colour used that is judged differently by the available predicates

Most reasonable backgrounds are either too light or too dark to pass the latter criterion, but people's idea of what is reasonable varies. For instance, black-on-green text is somewhat readable, but

  emacs -bg green -fg black

will give mostly bad default faces (for instance, the minibuffer prompt is almost invisible). With color-dark-p it becomes workable (attached diff).

Whether this is reason enough to add a defcustom is something I won't comment on. I doubt anyone will change it, whatever the default would be.

[dark.diff (application/octet-stream, attachment)]

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

Previous Next


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