From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Mark Bestley" Newsgroups: gmane.emacs.bugs Subject: bug#61188: 30.0.50; color-lighten-name seems not to work Date: Thu, 02 Feb 2023 18:32:50 +0000 Message-ID: References: <03DC6549-C68D-449B-92F8-BA3E9EB5AC5B@fastmail.co.uk> <87wn53iq99.fsf@rub.de> <83o7qe1rbi.fsf@gnu.org> <87ilgmmoj3.fsf@rub.de> <83wn51zfkh.fsf@gnu.org> <180e1ab1-287c-451b-bd43-6b858638df2f@app.fastmail.com> <83o7qdz4lh.fsf@gnu.org> <81E109CF-91D3-412A-87FC-2839ABFF4788@fastmail.co.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=d41d5634d4c6475fab3c23861bfab159 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22580"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Cyrus-JMAP/3.9.0-alpha0-107-g82c3c54364-fm-20230131.002-g82c3c543 Cc: Stephen Berman , 61188@debbugs.gnu.org To: "Eli Zaretskii" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Feb 02 19:34:25 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pNePf-0005g8-NL for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Feb 2023 19:34:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pNePN-0001RG-4V; Thu, 02 Feb 2023 13:34:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pNePK-0001Lp-Es for bug-gnu-emacs@gnu.org; Thu, 02 Feb 2023 13:34:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pNePK-000816-52 for bug-gnu-emacs@gnu.org; Thu, 02 Feb 2023 13:34:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pNePJ-00053n-TQ for bug-gnu-emacs@gnu.org; Thu, 02 Feb 2023 13:34:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Mark Bestley" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Feb 2023 18:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61188 X-GNU-PR-Package: emacs Original-Received: via spool by 61188-submit@debbugs.gnu.org id=B61188.167536280119395 (code B ref 61188); Thu, 02 Feb 2023 18:34:01 +0000 Original-Received: (at 61188) by debbugs.gnu.org; 2 Feb 2023 18:33:21 +0000 Original-Received: from localhost ([127.0.0.1]:35803 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pNeOe-00052l-TL for submit@debbugs.gnu.org; Thu, 02 Feb 2023 13:33:21 -0500 Original-Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:46021) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pNeOc-00052P-Eh for 61188@debbugs.gnu.org; Thu, 02 Feb 2023 13:33:19 -0500 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 9DA10320090F; Thu, 2 Feb 2023 13:33:11 -0500 (EST) Original-Received: from imap43 ([10.202.2.93]) by compute3.internal (MEProxy); Thu, 02 Feb 2023 13:33:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bestley.co.uk; h=cc:cc:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm2; t=1675362791; x=1675449191; bh=TG kNwq/Q8i6HP1IgnVelWBKhGHmaSpCJ/YAH+VQvkhw=; b=IMQSGrNtb2OXcmBK7F UbcgNQDoU/5wZoMLJLbUB5l5YSEgocUpO9l3FflE2YFf9vlI1K6oeQ2es7tb2bpa djEHZSesBJllHGUklKXQTi4laVDLi2+t7ffO+UIvWzY0jAdvKgOxZQo2YubvNVVD +eAPtA5/DH7TShn9bNybmDI0jer4sHJZqIbVQaPMUtEU3kKZqFqgirFrLxIC7H7Z DPyC10itReKGYpJ7rZFv5EHgmkqa3cjG+btVCXFyZKWhvWW9q7dC9/Op/efKULCi 0qD5Iey1fZUvIwlGMkF3koCawFXXqCBJbBxOTVG8zRWuZE84WYaFetiHLtxBO7YJ WyRQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1675362791; x=1675449191; bh=TGkNwq/Q8i6HP1IgnVelWBKhGHma SpCJ/YAH+VQvkhw=; b=OztlVvjYJ4bjBp1WBLhL3Xw+AdZGq9idi7aTFlVb+T2f 6khBlWUobwCc/evD2NPKFKrpjB3NzXF0S/MilYzdmVBHgVTCCULYQWPQaJMV/xgq El8a+BEWsQOBj3+9ulepJOI2DxF+xGOD6W9QzhW1lLmVlXWKR1NIuz1DfPeTYyKJ ZYsRDnFkM+YsSfcHRDfRVRImtHbtC9INAyMPF4Vrk1T729cqh6u/pFsHyJ3c7Pgv IewDyNAR0LZwt4lZIb3C9lIFSwX8jqGo055311fdfCmjZ94llrbyYmPSKcwXaUe4 GxevLqGEkYMVM7UPDHThwO47vfcvnVMharvc0q9uOA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudefkedguddutdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enhdfknhhvihhsihgslhgvucifohhrughsucdlhedtmdenucfjughrpefofgggkfgjfhff hffvvefutgesrgdtreerreertdenucfhrhhomhepfdforghrkhcuuegvshhtlhgvhidfuc eoghhnuhessggvshhtlhgvhidrtghordhukheqnecuggftrfgrthhtvghrnhepudejkeel jeethfejteffleegteevleejieeluefhueeileehvdffgfefheelgfeknecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepghhnuhessggvshhtlhgv hidrtghordhukh X-ME-Proxy: Feedback-ID: i4629427b:Fastmail Original-Received: by mailuser.nyi.internal (Postfix, from userid 501) id F27352D40074; Thu, 2 Feb 2023 13:33:10 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <81E109CF-91D3-412A-87FC-2839ABFF4788@fastmail.co.uk> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:254687 Archived-At: --d41d5634d4c6475fab3c23861bfab159 Content-Type: text/plain On Thu, 2 Feb 2023, at 15:46, Mark Bestley wrote: > * > >> On 1 Feb 2023, at 17:18, Eli Zaretskii wrote: >> >>> Date: Wed, 01 Feb 2023 14:11:13 +0000 >>> From: "Mark Bestley" >>> 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 --d41d5634d4c6475fab3c23861bfab159 Content-Type: text/html Content-Transfer-Encoding: quoted-printable


On Thu, 2 Fe= b 2023, at 15:46, Mark Bestley wrote:


On 1 = Feb 2023, at 17:18, Eli Zaretskii <eliz@gnu.org> wrote:
<= div>
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 corr= ect
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 i= t run for 28.2?

The test is in test/= lisp/color-tests.el.  The expected value is
exactly w= hat you said is wrong.

Surely lightening Black fully should give white
How so?  The 100 is the percentage of the present lumi= nance, and if
that is zero, why do you expect it to become= lighter?

See also the discussion in bug#54= 514, 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  "Blac= k" of any positive value gives Black - surely this cannot be correct.

A zero multiplied by any percentage st= ays zero, no?  If you want a
non-zero result, start w= ith something close to black, but not actually
black.
<= /div>
The issue is more with color-lighten-name a= nd 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 wh= ite makes sense.

So just multiplying hue may not give the expected re= sult 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 unde= rstand why then change was made but I think that there will be broken co= de around which used color-ligh= ten-name when emacs 29 is released.

= Basically manipulation of coper values is more com= plex 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 p= ercentage change to the hue the new code multiplies by the change.
So their is rationale to that but the comment for th= e function is not exact enough.
--
Mark



= --d41d5634d4c6475fab3c23861bfab159--