From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#55623: 29.0.50; Mention that (face-foreground 'default) can return "unspecified-fg" Date: Tue, 28 Jun 2022 14:37:54 -0700 Message-ID: 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> <83czfzo554.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35149"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Adam Porter , luangruo@yahoo.com, 55623-done@debbugs.gnu.org, visuweshm@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jun 28 23:39:13 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 1o6IvQ-0008w4-OJ for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 28 Jun 2022 23:39:12 +0200 Original-Received: from localhost ([::1]:54850 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o6IvP-0005Ev-7z for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 28 Jun 2022 17:39:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45060) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6IvG-0005BT-6R for bug-gnu-emacs@gnu.org; Tue, 28 Jun 2022 17:39:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34443) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o6IvF-0003nL-SS for bug-gnu-emacs@gnu.org; Tue, 28 Jun 2022 17:39:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o6IvF-0000VM-Pu for bug-gnu-emacs@gnu.org; Tue, 28 Jun 2022 17:39:01 -0400 Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Jun 2022 21:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 55623 X-GNU-PR-Package: emacs Mail-Followup-To: 55623@debbugs.gnu.org, stefan@marxist.se, visuweshm@gmail.com Original-Received: via spool by 55623-done@debbugs.gnu.org id=D55623.16564522841870 (code D ref 55623); Tue, 28 Jun 2022 21:39:01 +0000 Original-Received: (at 55623-done) by debbugs.gnu.org; 28 Jun 2022 21:38:04 +0000 Original-Received: from localhost ([127.0.0.1]:56571 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o6IuJ-0000Tw-NW for submit@debbugs.gnu.org; Tue, 28 Jun 2022 17:38:04 -0400 Original-Received: from mail-pj1-f41.google.com ([209.85.216.41]:54081) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o6IuG-0000Sr-54 for 55623-done@debbugs.gnu.org; Tue, 28 Jun 2022 17:38:01 -0400 Original-Received: by mail-pj1-f41.google.com with SMTP id d14so13801743pjs.3 for <55623-done@debbugs.gnu.org>; Tue, 28 Jun 2022 14:38:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:user-agent :mime-version:date:message-id:subject:to:cc; bh=RS1t42YfWMJ+pJppxZo7/8Sm2NqHlGR9d5Cvb/GqZ/M=; b=HKyP2fTAJ8FzDduSbq3JhwH+McV39ph2nKWuLote1hu+xxoHzAQp+7FCYEr8cc2A1w q15uo3FOOeMPeFb4eH8qNVUcDvcaOHRQWykZ8C+Y/cdOSgcNClnsbczpWX9bEiz6nvkA 5k7G/P7DaL32tqfLb1XFCjkcghyQZEb1ngKnas+ifvmd+ivQvIuyk7dqLXKBxzMqQeAU kvNwMTmmXI40cBVSxumTSik5ny7WnXTfMf0pfijsrO5McRzyuPLbGEyDQlIhhydIGu4c xhwIrmDq4EJtecPr6hT3AqOs1cierSrkq9M+F9Pk5OWqCAmgrDu2wW3qM0kBZvoY4yhk GF5A== X-Gm-Message-State: AJIora8DGI1jmFuENMDaOB4tFNT5l7rW7w3F/3de4nSACEpA1Yh6WsYB a5GAUqgMcIHUEsNJUFxxSH2/jCbWXx45M8wPSvs= X-Google-Smtp-Source: AGRyM1sJHDVwTcRgvKglO6KzzZXtmWgdWu3iP9Lxp++p6s9me+u9V7/uGvk/khRAw1XAtmIzTZv22LevQqPdY+gtSpI= X-Received: by 2002:a17:902:7c0d:b0:16b:7dd2:626c with SMTP id x13-20020a1709027c0d00b0016b7dd2626cmr6917721pll.152.1656452274431; Tue, 28 Jun 2022 14:37:54 -0700 (PDT) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 28 Jun 2022 14:37:54 -0700 In-Reply-To: <83czfzo554.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 27 May 2022 09:34:31 +0300") 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:235577 Archived-At: Eli Zaretskii writes: >> 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. It seems like this documentation bug was fixed, so I'm closing it. If this conclusion is incorrect and this is still an issue, please reply to this email (use "Reply to all" in your email client) and we can reopen the bug report.