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#55623: 29.0.50; Mention that (face-foreground 'default) can return "unspecified-fg" Date: Fri, 27 May 2022 09:34:31 +0300 Message-ID: <83czfzo554.fsf@gnu.org> References: <87ilpub287.fsf@gmail.com> <87o7zmjd2f.fsf@yahoo.com> <87czg2aw0q.fsf@gmail.com> <83pmk14uo4.fsf@gnu.org> <878rqpbqxm.fsf@gmail.com> <83tu9dpmlv.fsf@gnu.org> <87o7zla5on.fsf@gmail.com> <83pmk1pl8h.fsf@gnu.org> <4a17447f-c07f-b522-67a5-c81136dd4f4e@alphapapa.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="427"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, 55623@debbugs.gnu.org, visuweshm@gmail.com To: Adam Porter Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri May 27 08:36:20 2022 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 1nuTa7-000AWK-VH for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 27 May 2022 08:36:20 +0200 Original-Received: from localhost ([::1]:50850 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nuTa6-00057n-F5 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 27 May 2022 02:36:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39916) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nuTYs-00057V-FF for bug-gnu-emacs@gnu.org; Fri, 27 May 2022 02:35:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38570) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nuTYs-0008Ip-6I for bug-gnu-emacs@gnu.org; Fri, 27 May 2022 02:35:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nuTYr-0005rh-VS for bug-gnu-emacs@gnu.org; Fri, 27 May 2022 02:35: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: Fri, 27 May 2022 06:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55623 X-GNU-PR-Package: emacs Original-Received: via spool by 55623-submit@debbugs.gnu.org id=B55623.165363328422515 (code B ref 55623); Fri, 27 May 2022 06:35:01 +0000 Original-Received: (at 55623) by debbugs.gnu.org; 27 May 2022 06:34:44 +0000 Original-Received: from localhost ([127.0.0.1]:60700 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nuTYa-0005r5-7C for submit@debbugs.gnu.org; Fri, 27 May 2022 02:34:44 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:46574) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nuTYY-0005qs-CH for 55623@debbugs.gnu.org; Fri, 27 May 2022 02:34:42 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52842) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nuTYS-0008HV-Nk; Fri, 27 May 2022 02:34:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=4qepwTK4X5ANavCDzKAfEnzPKiAZU2TpA+nIArKcccU=; b=Bj2DPieeKlLu alfLUThIn/k9phm/FW7LVhpGuelHZ1JZRJkD0IeBKE9ByQE5qxHlbeqw6GyOXBhqBWpKM5iPTEuCj mbSjRsJDhvtbjFhbRxHw6mmnnLravgx603gvCjl3IHg/82tnveImt8r0D1MjmtfjN7EFzE33BsLCK ZxWseET18BouIZe7emx1t+cKO3cIQsv2XRkzcUoInCEUEdI1KX28Y6gY5Nsc8VC2jn5cqM4iWj48N qAKVddc5HE1FyNijfYIf7oA3gKuF7hgP4DIujdFLK3eTp8r6hQriuGtNOFnLi19V84sROUlIPhy0R bvNKt3/RTBjZtEruN35pDw==; Original-Received: from [87.69.77.57] (port=2116 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nuTYS-0000GL-4p; Fri, 27 May 2022 02:34:36 -0400 In-Reply-To: <4a17447f-c07f-b522-67a5-c81136dd4f4e@alphapapa.net> (message from Adam Porter on Fri, 27 May 2022 00:44:38 -0500) 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" Xref: news.gmane.io gmane.emacs.bugs:233151 Archived-At: > Date: Fri, 27 May 2022 00:44:38 -0500 > Cc: luangruo@yahoo.com, 55623@debbugs.gnu.org > From: Adam Porter > > (color-gradient > (color-name-to-rgb (face-foreground 'ement-room-list-very-recent > nil 'default)) > (color-name-to-rgb (face-foreground 'ement-room-list-recent > nil 'default)) > 6) > > When running on a TTY, face-foreground returns "unspecified-fg", which > causes color-name-to-rgb to return nil, which causes color-gradient to > signal an error. > > > Technically, these colors just tell Emacs not to emit a color-changing > > command when it writes text to the screen, or emit a command that > > tells the terminal driver "reset to your default color". But this is > > an implementation detail, and we cannot talk about it in the manual > > without explaining a lot of details about the inner workings of color > > support on TTY frames. > > Since the docstring says that the default face is always fully > specified, I thought that meant that the default face's foreground would > always have a defined, usable color name. Since "unspecified-fg" is not > in the manual, and apparently isn't usable by, e.g. color-name-to-rgb > (even on a graphical frame; and by "usable", I mean that it returns an > expected, useful color name), it seemed like an oversight in the manual > to not mention that string somewhere. These special pseudo-color names _are_ usable as colors, just not in every situation. For example, we cannot ask Emacs to produce RGB values for them, obviously. (If these pseudo-colors were the same as 'unspecified', you could trust us not to introduce such pseudo-colors in the first place, right?) > Theoretically, if "unspecified-fg" were documented somewhere, I could > have known that my code needs to account for it. I don't necessarily > need to know about the inner workings of color support on a TTY--only > that... > > (face-foreground 'default) > > ...may return "unspecified-fg" rather than a specific color name, and > that, therefore... > > (color-name-to-rgb (face-foreground 'default)) > > ...may return nil rather than a color name. These pseudo-colors were already mentioned in the doc string of color-values, which color-name-to-rgb calls. I've now mentioned them in a few more doc strings, including color-name-to-rgb and face-foreground. The additional text says something like On TTY frames, the returned color name can be "unspecified-fg", which stands for the unknown default foreground color of the display where the frame is displayed. > I think a sentence or two in the appropriate place could clear this up > and prevent users like me from running into this problem. e.g. > > Note that, on non-graphical frames, the default face's foreground and > background colors may be unspecified; in this case, those color names > may be the special values "unspecified-fg" and "unspecified-bg", > respectively. While these are in some senses legitimate color names > in Emacs, not all functions that expect color names as arguments may > handle these values as expected, so it may be necessary to check for > these special color names before calling such functions with them. This kind of vague description is not appropriate for the manual, which is supposed to _explain_ stuff, not just mention it. So I'd like for now to settle for the additions to the doc strings. After all, this issue didn't pop up since these pseudo-colors were introduced in Emacs 21, so it sounds like it's important only in some rare cases. Thanks.