From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#74055: 31.0.50; color-lighten-name not lightening black Date: Mon, 28 Oct 2024 19:24:28 +0200 Message-ID: <86cyjk6sz7.fsf@gnu.org> References: <86plnk766i.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37868"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, julien@danjou.info, noah@splode.com, 74055@debbugs.gnu.org To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Oct 28 18:26:03 2024 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 1t5TVD-0009ep-AG for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 28 Oct 2024 18:26:03 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t5TUh-0007rC-K3; Mon, 28 Oct 2024 13:25:31 -0400 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 1t5TUb-0007qP-RT for bug-gnu-emacs@gnu.org; Mon, 28 Oct 2024 13:25:25 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t5TUb-0005zJ-Ii for bug-gnu-emacs@gnu.org; Mon, 28 Oct 2024 13:25:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-version:References:In-Reply-To:From:Date:To:Subject; bh=oBptvgIhECfNB68DPj2smqSgB+vxDUERZVb7H7PtjUQ=; b=UGxBOQ8vXJubBmMpm7rNunDR2L3uUdL/12ke7Lxwc0frzKG2Ff9eIpegZHf2IMrmOJd8O5ZiFPH1Sz96TpIqNie85j3lLgV5WDSWyKyEWnl8EUcU/56mR9LwMnsMSrxd6WIYKE/51Ec0yf+1ERu+2YWrBAc9DHu+tOReU39uB/OKsAaEOVOTPCjDMfCuiGHpz7HdGn7mp+hCRjnkNWG5XNNWv/7ppK9LKTvH9xzd66yPqRwdfoSCnFkRPjsOV4u3/ka8O7Qxw8VdyN2LqLlVi1cO9FuHRmIqqUAamL/pg3OIBYFVAQCe+qnln4chMTY9W7SSL6sCz1LlDD9lPr//DA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t5TVB-00034I-PH for bug-gnu-emacs@gnu.org; Mon, 28 Oct 2024 13:26:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 Oct 2024 17:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74055 X-GNU-PR-Package: emacs Original-Received: via spool by 74055-submit@debbugs.gnu.org id=B74055.173013634611416 (code B ref 74055); Mon, 28 Oct 2024 17:26:01 +0000 Original-Received: (at 74055) by debbugs.gnu.org; 28 Oct 2024 17:25:46 +0000 Original-Received: from localhost ([127.0.0.1]:54602 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5TUv-0002y4-If for submit@debbugs.gnu.org; Mon, 28 Oct 2024 13:25:45 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40426) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5TUt-0002xm-7R for 74055@debbugs.gnu.org; Mon, 28 Oct 2024 13:25:44 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t5TUC-0005ko-9i; Mon, 28 Oct 2024 13:25:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=oBptvgIhECfNB68DPj2smqSgB+vxDUERZVb7H7PtjUQ=; b=j5rBd5tkYrBIwhYtcZ1D 8O6LxnXtHpksSZlWa5PVHf7xmKCCpc5ZqMh3g4jqRti6ipjm0RvhCYgvlOg7LltEU3/G8QCcaFduq QLVl/o8kTiOKZ0VAQB/kPNzMt7A37I6tGPlj8uJIow/zT515fU6mAdvuAKnqbLORqTlVycXd8GeBC WIYtf8h/LfXbHDvfaPbWriZ4j5VdFTXYNVr9RYGyBJrGtC8YxDB1+c4apJA4X7lkMZN/FLkkgcoe/ +vDZgUuvbHblt30SCKSACQaI7fJ3MYPRn3w1J9wx9GghWNDPgYoi1Zuk5iIhmE7cSszYlz1bGZbHi dmVN6TgIj64a2A==; In-Reply-To: (message from Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= on Mon, 28 Oct 2024 17:57:49 +0100) 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:294443 Archived-At: > From: Mattias Engdegård > Date: Mon, 28 Oct 2024 17:57:49 +0100 > Cc: Gerd Möllmann , > Julien Danjou , > 74055@debbugs.gnu.org, > Noah Friedman > > 28 okt. 2024 kl. 13.39 skrev Eli Zaretskii : > > > Our notion of "lighten color" seems to be to increase the color's > > luminance by P percent. Since the black color's luminance is zero, > > increasing that by 50% still yields zero. > > > > By contrast, the page you point to seems to interpret "lighten" to > > mean that P is the percentage of the full scale, not of the original > > color's luminance. > > > > This goes back to commit 656c2dd66e, which was supposed to fix > > bug#54514. But maybe Noah's interpretation of "lighten" was > > incorrect, and we should revert that change? OTOH, if we do revert > > it, then Noah's example will disagree with the above page. > > That change may have been made in haste. For example, it didn't touch the corresponding saturate and desaturate functions which use similar mechanics, so there is now an inconsistency in that respect. > > But which interpretation is better isn't obvious. It doesn't have much to do with colour theory per se. As luminance is already a percentage of sorts, it's not at all clear what it means by increasing it by a certain percentage. Personally I wouldn't use either function because of how ill-defined they are. Maybe there are widely-accepted de-facto standards for that? Or maybe we should support more than one interpretation, by way of some user option?