From unknown Wed Jun 25 00:21:48 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#3677 <3677@debbugs.gnu.org> To: bug#3677 <3677@debbugs.gnu.org> Subject: Status: 23.0.95; facemenu-read-color should not require match Reply-To: bug#3677 <3677@debbugs.gnu.org> Date: Wed, 25 Jun 2025 07:21:48 +0000 retitle 3677 23.0.95; facemenu-read-color should not require match reassign 3677 emacs submitter 3677 Jay Berkenbilt severity 3677 normal thanks From primary@qbilt.org Thu Jun 25 07:24:55 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 25 Jun 2009 14:24:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.7 required=4.0 tests=AWL,FOURLA,IMPRONONCABLE_1, MURPHY_WRONG_WORD2 autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n5PEOnKr003257 for ; Thu, 25 Jun 2009 07:24:51 -0700 Received: from mx10.gnu.org ([199.232.76.166]:34644) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1MJpsf-0001W5-41 for emacs-pretest-bug@gnu.org; Thu, 25 Jun 2009 10:24:49 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1MJpsb-0006f3-7d for emacs-pretest-bug@gnu.org; Thu, 25 Jun 2009 10:24:48 -0400 Received: from hermes.mail.tigertech.net ([64.62.209.72]:55270) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJpsa-0006eK-Jw for emacs-pretest-bug@gnu.org; Thu, 25 Jun 2009 10:24:45 -0400 Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 28EC1430264; Thu, 25 Jun 2009 07:24:40 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from motoko.argon.local (unknown [72.165.80.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 5518843025B; Thu, 25 Jun 2009 07:24:39 -0700 (PDT) From: Jay Berkenbilt To: emacs-pretest-bug@gnu.org Subject: 23.0.95; facemenu-read-color should not require match Message-ID: <20090625102438.2173776366.qww314159@motoko.argon.local> Date: Thu, 25 Jun 2009 10:24:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) [I apologize if this is a duplicate. M-x report-emacs-bug doesn't appear to have called my sendmail-send-it function, so my original report is likely to be rejected as spam from many recipients.] M-x set-cursor-color RET #9ef RET -> [no match] The same thing happens with set-foreground-color and set-background-color, all of which call facemenu-read-color, but not with set-face-foreground and set-face-background, which do not. All above mentioned functions do completing reads on color names, which is appropriate, but they should also accept #xxx, #xxxxxx, rgb:xx/xx/xx, etc. If you do M-: (set-cursor-color "#9ef"), it works, so this is clearly a case of the wrong kind of completing read being done. In facemenu-read-color, in the let statement, require-match is initialized this way: (require-match (not (eq window-system 'ns))) I believe it should always have the value nil so that people are free to enter colors in alternative ways. In GNU Emacs 23.0.95.1 (i686-pc-linux-gnu, GTK+ Version 2.10.4) of 2009-06-23 on motoko.argon.local Windowing system distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--prefix=/opt/tps/packages/linux.ix86.rhel5/emacs-23.0.95-1'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 value of $XMODIFIERS: @im=none locale-coding-system: utf-8-unix default-enable-multibyte-characters: t Major mode: Conf[Xdefaults] Minor modes in effect: diff-auto-refine-mode: t which-function-mode: t tooltip-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t global-auto-composition-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: C-n C-n C-n C-n C-b C-d 9 C-d e C-x C-s C-p C-p C-p C-p C-b C-b C-d 8 d C-d C-x C-s C-d e C-x C-s C-x o C-v C-x C-x o C-x o C-b C-b C-b C-d d C-n C-n C-n C-n e C-x C-s C-x C-s C-x 0 M-< C-v C-v C-v C-v C-v C-v C-v C-v C-v M-v M-v C-SPC C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-g M-v M-v M-v M-v M-v C-x b C-f C-f C-b C-d b C-n C-n C-n C-n c C-x C-s C-x C-s C-x b C-s s k y C-x b C-x v u y e s C-n C-n C-n C-n C-k C-z C-o M-b 0 9 e f C-k C-p C-p C-p C-p 8 d e C-x C-s C-n C-n C-n C-n C-n M-b C-k b l a c k C-x C-s M-x C-g C-x b C-g C-x C-f ~ / X r c o C-s c u r s o r C-z C-o C-s C-s C-s C-e C-l M-b C-k 9 e f C-x b C-x b C-x C-s C-x b C-x b M-x s e t SPC c u # 9 9 e e f f M-p C-k ' # 9 e f C-g M-: ( s e t - c u r s o r - c o l o r SPC " # d 9 0 e f e f " ) C-a C-e M-x r e p o r t SPC b e m SPC b SPC Recent messages: Saving file /home/jberkenb/.local/share/themes/qtheme/openbox-3/themerc... Wrote /home/jberkenb/.local/share/themes/qtheme/openbox-3/themerc Quit [2 times] Note: file is write protected Mark saved where search started Checking out /home/jberkenb/Xresources/color...done Mark saved where search started Saving file /home/jberkenb/Xresources/color... Wrote /home/jberkenb/Xresources/color Quit nil From cyd@stupidchicken.com Sat Aug 15 22:26:37 2009 Received: (at 3677-done) by emacsbugs.donarmstrong.com; 16 Aug 2009 05:26:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.0 required=4.0 tests=AWL,IMPRONONCABLE_1, MURPHY_WRONG_WORD2 autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7G5Qaq6004145 for <3677-done@emacsbugs.donarmstrong.com>; Sat, 15 Aug 2009 22:26:37 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 6B1BD57E21C; Sun, 16 Aug 2009 01:27:35 -0400 (EDT) From: Chong Yidong To: Jay Berkenbilt Cc: 3677-done@debbugs.gnu.org Subject: Re: 23.0.95; facemenu-read-color should not require match Date: Sun, 16 Aug 2009 01:27:35 -0400 Message-ID: <874os8ba60.fsf@cyd.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > M-x set-cursor-color RET #9ef RET > > -> [no match] > > The same thing happens with set-foreground-color and > set-background-color, all of which call facemenu-read-color, but not > with set-face-foreground and set-face-background, which do not. All > above mentioned functions do completing reads on color names, which is > appropriate, but they should also accept #xxx, #xxxxxx, rgb:xx/xx/xx, > etc. If you do M-: (set-cursor-color "#9ef"), it works, so this is > clearly a case of the wrong kind of completing read being done. Thanks for the bug report. I've hacked up the completion function so that it allows any defined colors, including RGB triplets. From drew.adams@oracle.com Sun Aug 16 07:56:30 2009 Received: (at 3677-done) by emacsbugs.donarmstrong.com; 16 Aug 2009 14:56:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.9 required=4.0 tests=AWL,FOURLA,IMPRONONCABLE_1, MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7GEuTcL002607 for <3677-done@emacsbugs.donarmstrong.com>; Sun, 16 Aug 2009 07:56:30 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n7GEuG6i029918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 16 Aug 2009 14:56:18 GMT Received: from abhmt009.oracle.com (abhmt009.oracle.com [141.146.116.18]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n7GEuMwu002165; Sun, 16 Aug 2009 14:56:23 GMT Received: from dradamslap1 (/141.144.88.67) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 16 Aug 2009 07:56:19 -0700 From: "Drew Adams" To: "'Chong Yidong'" , "'Jay Berkenbilt'" Cc: <3677-done@debbugs.gnu.org> References: <874os8ba60.fsf@cyd.mit.edu> Subject: RE: 23.0.95; facemenu-read-color should not require match Date: Sun, 16 Aug 2009 07:56:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <874os8ba60.fsf@cyd.mit.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcoeMiAlKZx0WMRHQGqrjkSG3uLmWQATpKkg X-Source-IP: abhmt009.oracle.com [141.146.116.18] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4A881E14.0148:SCFSTAT5015188,ss=1,fgs=0 > > M-x set-cursor-color RET #9ef RET > > > > -> [no match] > > > > The same thing happens with set-foreground-color and > > set-background-color, all of which call facemenu-read-color, but not > > with set-face-foreground and set-face-background, which do not. All > > above mentioned functions do completing reads on color > names, which is > > appropriate, but they should also accept #xxx, #xxxxxx, > rgb:xx/xx/xx, > > etc. If you do M-: (set-cursor-color "#9ef"), it works, so this is > > clearly a case of the wrong kind of completing read being done. > > Thanks for the bug report. I've hacked up the completion function so > that it allows any defined colors, including RGB triplets. 1. I don't understand your change. Why define a `completer' function here, instead of just using `completing-read' directly as before? And you still pass `t' as the REQUIRE-MATCH parameter, so it's not clear to me how this accepts #RRRGGGBBB colors. I didn't try it - I assume it works if you say it does, but I don't see why it would or why the completer function is needed here. 2. Why don't you just use the function `read-color', defined in faces.el? That's exactly what it's for - it handles all colors correctly, including both named colors and #RRRGGGBBB (hex RGB string) colors. ,---- | read-color is an interactive compiled Lisp function in `faces.el'. | | (read-color &optional PROMPT CONVERT-TO-RGB-P ALLOW-EMPTY-NAME-P | MSG-P) | | Read a color name or RGB hex value: #RRRRGGGGBBBB. | Completion is available for color names, but not for RGB hex strings. | If the user inputs an RGB hex string, it must have the form | #XXXXXXXXXXXX or XXXXXXXXXXXX, where each X is a hex digit. The | number of Xs must be a multiple of 3, with the same number of Xs for | each of red, green, and blue. The order is red, green, blue. | | In addition to standard color names and RGB hex values, the following | are available as color candidates. In each case, the corresponding | color is used. | | * `foreground at point' - foreground under the cursor | * `background at point' - background under the cursor | | Checks input to be sure it represents a valid color. If not, raises | an error (but see exception for empty input with non-nil | ALLOW-EMPTY-NAME-P). | | Optional arg PROMPT is the prompt; if nil, uses a default prompt. | | Interactively, or with optional arg CONVERT-TO-RGB-P non-nil, converts | an input color name to an RGB hex string. Returns the RGB hex string. | | Optional arg ALLOW-EMPTY-NAME-P controls what happens if the user | enters an empty color name (that is, just hits `RET'). If non-nil, | then returns an empty color name, "". If nil, then raises an error. | Programs must test for "" if ALLOW-EMPTY-NAME-P is non-nil. They | can then perform an appropriate action in case of empty input. | | Interactively, or with optional arg MSG-P non-nil, echoes the color in | a message. `---- You can forget about #1 - I'm just curious. I'm probably missing something here. But #2 seems pertinent, at least. Using `read-color' seems like the better fix. From cyd@stupidchicken.com Sun Aug 16 11:10:00 2009 Received: (at 3677-done) by emacsbugs.donarmstrong.com; 16 Aug 2009 18:10:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=AWL,MURPHY_WRONG_WORD1, MURPHY_WRONG_WORD2 autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7GI9x8G005544 for <3677-done@emacsbugs.donarmstrong.com>; Sun, 16 Aug 2009 11:10:00 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id D163457E25D; Sun, 16 Aug 2009 14:10:58 -0400 (EDT) From: Chong Yidong To: "Drew Adams" Cc: "'Jay Berkenbilt'" , <3677-done@debbugs.gnu.org> Subject: Re: 23.0.95; facemenu-read-color should not require match References: <874os8ba60.fsf@cyd.mit.edu> Date: Sun, 16 Aug 2009 14:10:58 -0400 In-Reply-To: (Drew Adams's message of "Sun, 16 Aug 2009 07:56:44 -0700") Message-ID: <87my5zr5n1.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "Drew Adams" writes: > 1. I don't understand your change. Why define a `completer' function > here, instead of just using `completing-read' directly as before? And > you still pass `t' as the REQUIRE-MATCH parameter, so it's not clear > to me how this accepts #RRRGGGBBB colors. The completer function checks `color-defined-p' if the color passed by the user is not a predefined color name. That's how it accepts RGB triplets. > 2. Why don't you just use the function `read-color', defined in > faces.el? That's exactly what it's for - it handles all colors > correctly, including both named colors and #RRRGGGBBB (hex RGB string) > colors. That's true, we should probably merge facemenu-read-color and read-color. From drew.adams@oracle.com Sun Aug 16 11:47:53 2009 Received: (at 3677-done) by emacsbugs.donarmstrong.com; 16 Aug 2009 18:47:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,MURPHY_WRONG_WORD1, MURPHY_WRONG_WORD2 autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7GIlqcq011929 for <3677-done@emacsbugs.donarmstrong.com>; Sun, 16 Aug 2009 11:47:53 -0700 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n7GIldGV007803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 16 Aug 2009 18:47:40 GMT Received: from abhmt010.oracle.com (abhmt010.oracle.com [141.146.116.19]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n7GImNVY012252; Sun, 16 Aug 2009 18:48:23 GMT Received: from dradamslap1 (/141.144.88.37) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 16 Aug 2009 11:47:42 -0700 From: "Drew Adams" To: "'Chong Yidong'" Cc: "'Jay Berkenbilt'" , <3677-done@debbugs.gnu.org> References: <874os8ba60.fsf@cyd.mit.edu> <87my5zr5n1.fsf@cyd.mit.edu> Subject: RE: 23.0.95; facemenu-read-color should not require match Date: Sun, 16 Aug 2009 11:48:07 -0700 Message-ID: <846C77DF6AB64E6E9F0E264A91DA49F5@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoenPPy5AEXL5/DQAW2TIAJX3CBogAAg9fw In-Reply-To: <87my5zr5n1.fsf@cyd.mit.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt010.oracle.com [141.146.116.19] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4A88544F.006F:SCFSTAT5015188,ss=1,fgs=0 > > 1. I don't understand your change. Why define a `completer' > > functionhere, instead of just using `completing-read' directly as > > before? And you still pass `t' as the REQUIRE-MATCH parameter, > > so it's not clear to me how this accepts #RRRGGGBBB colors. > > The completer function checks `color-defined-p' if the color passed by > the user is not a predefined color name. That's how it accepts RGB > triplets. Ah, right; got it. Thx. > > 2. Why don't you just use the function `read-color', defined in > > faces.el? That's exactly what it's for - it handles all colors > > correctly, including both named colors and #RRRGGGBBB (hex > > RGB string) colors. > > That's true, we should probably merge facemenu-read-color and > read-color. Just use `read-color'. There is nothing additional that `facemenu-read-color' offers, except that it recognizes `facemenu-color-alist'. `facemenu-color-alist' is only an internal variable, and it is not defined (beyond nil) or used anywhere in the Emacs code. Its only purpose was to provide a list of colors for completion, AFAIK. And if all supported colors are now included as completions anyway, then it no longer serves a purpose. I suspect perhaps it was provided originally as a parallel to `facemenu-listed-faces', which is now a defcustom. In any case, it seems that it is only a vestige (cruft). BTW, using your definition of `facemenu-read-color', I see two curious things (probably having to do with the general completion code, not `facemenu-read-color'): 1. Hitting TAB without typing anything at the prompt shows "Complete, but not unique". That is clearly incorrect. The empty string is not a valid color name. 2. Typing #333333333 TAB shows "Complete, but not unique". Hitting TAB again then shows "Sole completion". That sounds contradictory. I suspect (without investigating, so probably wrongly) that it thinks the completion is not unique because it cannot know what the completer function might also include as another valid completion. If so, then it would presumably always say "Complete, but not unique" whenever you use a function-valued COLLECTION arg. If that's the case, then the message should perhaps be changed to not be so definitive. Currently, it is saying that there are in fact other completions with the same prefix, even though #333333333 is complete. (That's true; #333333333333 is valid too, but Emacs support doesn't reach beyond 4 hex digits per component, even internally, AFAIK.) Is it saying that because it knows that there are such other completions, or is it saying that because it just doesn't know? If the latter (which I suspect), then the message should be something more like "Complete, but not necessarily unique". If we use `read-color' instead, then the behavior is more natural and more usual: 1. TAB with no typed input immediately shows the completion candidates (instead of "Complete, but not unique"). 2. TAB after typing #333333333 shows "No match", which is true - it matches no color name (all of the candidates are color names). However, completion is lax, so when you hit RET the #333333333 is accepted correctly. This is the normal behavior for lax completion - it is what users are used to. From unknown Wed Jun 25 00:21:48 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 14 Sep 2009 14:24:12 +0000 User-Agent: Fakemail v42.6.9 # A New Hope # A long time ago, in a galaxy far, far away # something happened. # # Magically this resulted in the following # action being taken, but this fake control # message doesn't tell you why it happened # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator