Subject: bug#41544: 26.3; Possible incorrect results from color-distance

From: Mattias Engdegård <[email-masked]>
Date: Wed, 19 Aug 2020 13:28:52 +0200

[CC list trimmed]

19 aug. 2020 kl. 12.11 skrev Lars Ingebrigtsen <[email-masked]>:

> I'm not quite sure I follow you here, but could these other computations
> also be fixed, with a defcustom to switched between the two computation
> methods?

Technically yes, but is there is a reason for users to adjust this particular behaviour? Users dissatisfied with the outcome of the existing algorithms typically curse and set colours explicitly (or suffer in silence); they are unlikely to set a 'use different algorithm' variable.

To be precise, the computations I suppose we are talking about are located in:

 frame-set-background-mode (frame.el:1184)
 xterm-maybe-set-dark-background-mode (xterm.el:1122)
 rxvt-set-background-mode (rxvt.el:198)
 terminal-init-w32console (w32console.el:89)

which all use the predicate (r+g+b)/3 < 0.6 to determine if a colour is dark.
It is also mentioned in a comment in pc-win.el:57.

I believe it to be suboptimal but have no plans to do anything about it.