bug#61188: 30.0.50; color-lighten-name seems not to work

["Mark Bestley" <gnu@bestley.co.uk>]

[-- Attachment #1: Type: text/plain, Size: 2718 bytes --]



On Thu, 2 Feb 2023, at 15:46, Mark Bestley wrote:
>  * 
> 
>> On 1 Feb 2023, at 17:18, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>>> Date: Wed, 01 Feb 2023 14:11:13 +0000
>>> From: "Mark Bestley" <gnu@bestley.co.uk>
>>> Cc: 61188@debbugs.gnu.org
>>> 
>>>> So I guess the current behavior is the intended one, and we should
>>>> close this bug as wontfix?
>>> 
>>> No - I think the way 28.2 worked was correct. (for impact see highlight-indent.el which now does not work with a black background )
>> 
>> But by changing the tests to match what Emacs does now we explicitly
>> said that we disagree, and that the current behavior is the correct
>> one.
>> 
>>> What is the expected value of (color-lighten-name  "Black" 100) as I don't know where that test is. I would think the test is wrong. Did it run for 28.2?
>> 
>> The test is in test/lisp/color-tests.el.  The expected value is
>> exactly what you said is wrong.
>> 
>>> Surely lightening Black fully should give white
>> 
>> How so?  The 100 is the percentage of the present luminance, and if
>> that is zero, why do you expect it to become lighter?
>> 
>> See also the discussion in bug#54514, which was exactly about that.
> 
> I don't see a discussion there.
> But I do understand and accept the rationale for changing * color-lighten-hsl*
> 
> 
> 
>> 
>>> In 30 olor-lighten-name  "Black" of any positive value gives Black - surely this cannot be correct.
>> 
>> A zero multiplied by any percentage stays zero, no?  If you want a
>> non-zero result, start with something close to black, but not actually
>> black.
> The issue is more with color-lighten-name and the use it has in highlight-indent.el
> Here the background colour is increased or darkened so that a new background is  distinguishable from the original and it does that via varying the hue. In those terms increasing the hue from black to shades of grey and 100% takes you to white makes sense.
> 
> So just multiplying hue may not give the expected result here, The old reasoning for color-by-name might make some sense but I don't think we have the rationale why that was chosen.
> 
> So I understand why then change was made but I think that there will be broken code around which used color-lighten-name when emacs 29 is released.
> 
> Basically manipulation of coper values is more complex than at first thought.
> 
> I'll report this issue to highlight-indent.el and I think this bug can be closed,
Sorry for the further post 

I looked at the old tests for color-lighten-hsl and see their rationale.

The old code added the percentage change to the hue the new code multiplies by the change.
So their is rationale to that but the comment for the function is not exact enough.
--
Mark



[-- Attachment #2: Type: text/html, Size: 7363 bytes --]