29 maj 2020 kl. 19.52 skrev Tom Tromey : > However, my main concern is just whether it still picks reasonably > contrasting colors when editing CSS. If it does, then that's good > enough for me. Thank you for the kind words. I couldn't leave well enough alone, of course. Emacs does this sort of is-this-colour-dark computation in at least 7 different places, with different algorithms: * max(r,g,b) < 0.5 * r+g+b < 0.5*3 * color-distance(c, "black") < 292485 They aren't really satisfactory: for example, saturated blue (#0000ff) is quite clearly 'dark', yet the first algorithm considers it 'light'. Colour distance isn't quite right either -- the implemented formula is intended to measure distances between colours, not brightness. For example, it considers #ff0000 to be closer than #0000ff to black, but the red is clearly brighter. I tentatively went with your suggested 0.299r + 0.587g + 0.114g, with a cut-off value of 0.58 to make saturated blue and red 'dark' and green 'light'. This is not a correct luma calculation since there is no gamma correction, but it might do for this purpose. 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?)