From unknown Sun Jun 15 14:44:41 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#15900 <15900@debbugs.gnu.org> To: bug#15900 <15900@debbugs.gnu.org> Subject: Status: 24.3.50; foreground-color-at-point returns wrong results Reply-To: bug#15900 <15900@debbugs.gnu.org> Date: Sun, 15 Jun 2025 21:44:41 +0000 retitle 15900 24.3.50; foreground-color-at-point returns wrong results reassign 15900 emacs submitter 15900 Michael Heerdegen severity 15900 minor thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 21:05:29 2013 Received: (at submit) by debbugs.gnu.org; 15 Nov 2013 02:05:30 +0000 Received: from localhost ([127.0.0.1]:52886 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vh8mm-0005FR-P3 for submit@debbugs.gnu.org; Thu, 14 Nov 2013 21:05:29 -0500 Received: from eggs.gnu.org ([208.118.235.92]:47251) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vh8mk-0005FB-E9 for submit@debbugs.gnu.org; Thu, 14 Nov 2013 21:05:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vh8mX-0002I1-Tc for submit@debbugs.gnu.org; Thu, 14 Nov 2013 21:05:20 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_40,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:50258) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vh8mX-0002Hw-QM for submit@debbugs.gnu.org; Thu, 14 Nov 2013 21:05:13 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48957) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vh8mR-0005Nr-KO for bug-gnu-emacs@gnu.org; Thu, 14 Nov 2013 21:05:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vh8mL-00023r-FH for bug-gnu-emacs@gnu.org; Thu, 14 Nov 2013 21:05:07 -0500 Received: from mout.web.de ([212.227.15.3]:59249) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vh8mL-0001zp-55 for bug-gnu-emacs@gnu.org; Thu, 14 Nov 2013 21:05:01 -0500 Received: from drachen.dragon ([90.186.115.39]) by smtp.web.de (mrweb102) with ESMTPA (Nemesis) id 0MeBDG-1W4tEK3xIk-00PuV8 for ; Fri, 15 Nov 2013 03:04:59 +0100 From: Michael Heerdegen To: bug-gnu-emacs@gnu.org Subject: 24.3.50; foreground-color-at-point returns wrong results Date: Fri, 15 Nov 2013 03:04:56 +0100 Message-ID: <87siuyxvw7.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:Y4797u+oDRsFM9UiepFJenVKytp2uUm0mXBcv98dfGkebPcVCwm GIkX9rXzHZl+0lbkMEW9h3NdzzG8JUSYVkL16kT/eRLPfhk5zO9spYdva78KFs6o1cSGMJX dWJxlRPxlENnFz94n3QLA2XSxtziBCh5u8wex/eqKvvpnZLqDVJR4/K8iL6KvZ5dByl7hvx KazF0xxVNh5tWPooCY5Hw== X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Hello, `foreground-color-at-point' doesn't return the expected result when there are several faces at point present. For example, on the red subject in a Gnus article buffer, or on a blue link in w3m, it returns "black". Looking at the code, I see that `foreground-color-at-point' uses (face-at-point) i.e., it looks only at one face and disregards the others. This is especially meaningless when this first face doesn't specify any foreground at all. Thanks, Michael. P.S. Some background: I'm working on an addition to stripe-buffer.el that changes the foreground color continuously, instead of changing the background. This is for better readability. I want to keep the foreground colors already present, so that e.g. links in w3m are still recognizable. Paragraphs in italic can be colored OTOH. So, what I need is a reliable `foreground-color-at-point'. Tips and alternatives welcome. In GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.8.4) of 2013-11-13 on drachen Windowing system distributor `The X.Org Foundation', version 11.0.11403000 System Description: Debian GNU/Linux testing (jessie) Configured using: `configure --prefix=/usr/local/built/' From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 14 21:47:57 2013 Received: (at 15900) by debbugs.gnu.org; 15 Nov 2013 02:47:57 +0000 Received: from localhost ([127.0.0.1]:52913 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vh9Rs-0006J2-JC for submit@debbugs.gnu.org; Thu, 14 Nov 2013 21:47:56 -0500 Received: from mout.web.de ([212.227.17.12]:50153) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vh9Rq-0006Io-Dg for 15900@debbugs.gnu.org; Thu, 14 Nov 2013 21:47:55 -0500 Received: from drachen.dragon ([90.186.115.39]) by smtp.web.de (mrweb103) with ESMTPA (Nemesis) id 0McFLP-1Vxzk512Ln-00JdZQ for <15900@debbugs.gnu.org>; Fri, 15 Nov 2013 03:47:48 +0100 From: Michael Heerdegen To: 15900@debbugs.gnu.org Subject: Re: bug#15900: 24.3.50; foreground-color-at-point returns wrong results References: <87siuyxvw7.fsf@web.de> Date: Fri, 15 Nov 2013 03:47:41 +0100 In-Reply-To: <87siuyxvw7.fsf@web.de> (Michael Heerdegen's message of "Fri, 15 Nov 2013 03:04:56 +0100") Message-ID: <87mwl6xtwy.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:2OZJPE0aGlUDBwPh3XzVHF9p85ptNxRw1Q0DOqPlnZM0NA2Ju5+ ZgY4Xj3LdqZw+l/+7aRsrE4AW6ppRflgR9bExQaGp0G9R9u2zQ4EXTmFrO+yt06CWHglyoy w+MHhZqY6grGxBamnsWLRHDdfrgh7A0UGUCGpX3j5q8OZYOuXKYpBi+mF4mDyFBUXw8Mw3G WkvyIaOL54GqcvzXmELDw== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 15900 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Michael Heerdegen writes: > Hello, > > `foreground-color-at-point' doesn't return the expected result when > there are several faces at point present. > > For example, on the red subject in a Gnus article buffer, or on a blue > link in w3m, it returns "black". Looking at the code, I see that > `foreground-color-at-point' uses > > (face-at-point) > > i.e., it looks only at one face and disregards the others. This is > especially meaningless when this first face doesn't specify any > foreground at all. Even (face-at-point nil 'multiple) is not correct. Evaluated in w3m with point on a link, i get ==> (w3m-current-anchor) This is what I get for M-1 C-x = (excerpt) ,---------------------------------------------------------------------- | There is an overlay here: | From 7785 to 7798 | evaporate t | face w3m-current-anchor | w3m-momentary-overlay t | | | There are text properties here: | balloon-help nil | face (w3m-anchor) | help-echo [Show] | keymap [Show] | mouse-face highlight | rear-nonsticky t | w3m-anchor-sequence 75 | w3m-anchor-title nil | w3m-balloon-help [Show] | w3m-href-anchor [Show] | w3m-name-anchor [Show] | w3m-name-anchor2 ("showmodes" "gb_70") | w3m-safe-url-regexp nil `---------------------------------------------------------------------- `face-at-point' disregards the face text property, it only returns the face overlay property. > So, what I need is a reliable `foreground-color-at-point'. Tips and > alternatives welcome. I try to use something like this as a workaround now: --8<---------------cut here---------------start------------->8--- (cl-some (lambda (face) (not (memq (face-foreground face nil t) `(nil ,(face-attribute 'default :foreground))))) (cl-mapcan (lambda (face-or-list) (if (facep face-or-list) (list face-or-list) face-or-list)) (list (get-text-property (point) 'face) (get-text-property (point) 'font-lock-face)))) --8<---------------cut here---------------end--------------->8--- Regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 03:27:24 2013 Received: (at 15900) by debbugs.gnu.org; 15 Nov 2013 08:27:24 +0000 Received: from localhost ([127.0.0.1]:53935 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhEkN-0001KZ-3V for submit@debbugs.gnu.org; Fri, 15 Nov 2013 03:27:23 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:56619) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhEkJ-0001KH-SF for 15900@debbugs.gnu.org; Fri, 15 Nov 2013 03:27:21 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MWA00500PV5JU00@a-mtaout22.012.net.il> for 15900@debbugs.gnu.org; Fri, 15 Nov 2013 10:27:13 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MWA005BPQ5DJI20@a-mtaout22.012.net.il>; Fri, 15 Nov 2013 10:27:13 +0200 (IST) Date: Fri, 15 Nov 2013 10:26:58 +0200 From: Eli Zaretskii Subject: Re: bug#15900: 24.3.50; foreground-color-at-point returns wrong results In-reply-to: <87siuyxvw7.fsf@web.de> X-012-Sender: halo1@inter.net.il To: Michael Heerdegen Message-id: <83li0qhxyl.fsf@gnu.org> References: <87siuyxvw7.fsf@web.de> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15900 Cc: 15900@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Michael Heerdegen > Date: Fri, 15 Nov 2013 03:04:56 +0100 > > `foreground-color-at-point' doesn't return the expected result when > there are several faces at point present. > > For example, on the red subject in a Gnus article buffer, or on a blue > link in w3m, it returns "black". Looking at the code, I see that > `foreground-color-at-point' uses > > (face-at-point) > > i.e., it looks only at one face and disregards the others. This is > especially meaningless when this first face doesn't specify any > foreground at all. As you later discovered, even (face-at-point nil t) doesn't do the job. Which doesn't surprise me a bit: this kind of things cannot be done reliably from Lisp, even at a price of the kind of obfuscated code that face-at-point and foreground-color-at-point use. It is much simpler to write a C primitive that simulates the display, then returns the resulting face at a given character position, a simple and straightforward task on the C level, something the display engine does all the time. > P.S. Some background: I'm working on an addition to stripe-buffer.el > that changes the foreground color continuously, instead of changing the > background. This is for better readability. > > I want to keep the foreground colors already present, so that e.g. links > in w3m are still recognizable. Paragraphs in italic can be colored > OTOH. > > So, what I need is a reliable `foreground-color-at-point'. Tips and > alternatives welcome. Why can't you detect that a portion of text is covered by specific properties (e.g., one of a list of known properties), and leave those portions alone? From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 17:18:24 2013 Received: (at 15900) by debbugs.gnu.org; 15 Nov 2013 22:18:24 +0000 Received: from localhost ([127.0.0.1]:56304 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhRia-00009m-6m for submit@debbugs.gnu.org; Fri, 15 Nov 2013 17:18:24 -0500 Received: from mout.web.de ([212.227.17.12]:60181) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhRiX-00009X-QN for 15900@debbugs.gnu.org; Fri, 15 Nov 2013 17:18:22 -0500 Received: from drachen.dragon ([90.186.185.213]) by smtp.web.de (mrweb003) with ESMTPA (Nemesis) id 0M4ZVE-1VVFQQ1UlA-00ygBa for <15900@debbugs.gnu.org>; Fri, 15 Nov 2013 23:18:15 +0100 From: Michael Heerdegen To: Eli Zaretskii Subject: Re: bug#15900: 24.3.50; foreground-color-at-point returns wrong results References: <87siuyxvw7.fsf@web.de> <83li0qhxyl.fsf@gnu.org> Date: Fri, 15 Nov 2013 23:18:11 +0100 In-Reply-To: <83li0qhxyl.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 15 Nov 2013 10:26:58 +0200") Message-ID: <878uwpgvh8.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:n9Ksv1+bpEeWDIBVmqGb6UuLyq90vZYoTdl2aRyJVK3VJT44RJ1 wAE0RJsxVsVKRkOl+3Oeu0GyisEqZk4ijByvwHLXwdy0UsiewXM8CX2NVX+RuvEF/zVmCYb uw+uDUVMdUQuhwUiqSc/xejQx9+BqI3La7RIGRTvy3tHjQBtqQ/VFtyyMgvd3SIt0WzbwLX I1MlDCCeK0LqvNOHjFELQ== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 15900 Cc: 15900@debbugs.gnu.org, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Hello, CCing Drew cause the Change Log mentions him with regard to `foreground-color-at-point'. Eli Zaretskii writes: > As you later discovered, even (face-at-point nil t) doesn't do the > job. > > Which doesn't surprise me a bit: this kind of things cannot be done > reliably from Lisp, even at a price of the kind of obfuscated code > that face-at-point and foreground-color-at-point use. It is much > simpler to write a C primitive that simulates the display, then > returns the resulting face at a given character position, a simple and > straightforward task on the C level, something the display engine does > all the time. That sounds good. Can we just do that? > > P.S. Some background: I'm working on an addition to stripe-buffer.el > > that changes the foreground color continuously, instead of changing the > > background. This is for better readability. > > > > I want to keep the foreground colors already present, so that e.g. links > > in w3m are still recognizable. Paragraphs in italic can be colored > > OTOH. > > > > So, what I need is a reliable `foreground-color-at-point'. Tips and > > alternatives welcome. > > Why can't you detect that a portion of text is covered by specific > properties (e.g., one of a list of known properties), and leave those > portions alone? What do you mean with "properties" - text and overlay properties? If faces are among them, I still must figure out if one of these faces changes the foreground. If not, i.e., if a face e.g. just underlines, I do want to color the text nevertheless. Probably I didn't understand what you meant. This expression works ok for me: --8<---------------cut here---------------start------------->8--- (cl-some (lambda (face) (not (memq (face-foreground face nil t) `(nil ,(face-attribute 'default :foreground) "unspecified-fg" "unspecified-bg")))) (cl-mapcan (lambda (face-or-list) (if (facep face-or-list) (list face-or-list) face-or-list)) (list (get-text-property (point) 'face) (get-text-property (point) 'font-lock-face)))) --8<---------------cut here---------------end--------------->8--- Overlays are not covered by this - which is not even necessary, because overlays have priorities that can be controlled. Thanks, Michael. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 19:26:27 2013 Received: (at 15900) by debbugs.gnu.org; 16 Nov 2013 00:26:27 +0000 Received: from localhost ([127.0.0.1]:56350 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhTiU-0003G9-QD for submit@debbugs.gnu.org; Fri, 15 Nov 2013 19:26:27 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:45924) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhTiS-0003Fu-33 for 15900@debbugs.gnu.org; Fri, 15 Nov 2013 19:26:25 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rAG0QHfl032614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Nov 2013 00:26:18 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAG0QFrM019835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Nov 2013 00:26:17 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAG0QFnH017161; Sat, 16 Nov 2013 00:26:15 GMT MIME-Version: 1.0 Message-ID: Date: Fri, 15 Nov 2013 16:26:15 -0800 (PST) From: Drew Adams To: Michael Heerdegen , Eli Zaretskii Subject: RE: bug#15900: 24.3.50; foreground-color-at-point returns wrong results References: <87siuyxvw7.fsf@web.de> <83li0qhxyl.fsf@gnu.org> <878uwpgvh8.fsf@web.de> In-Reply-To: <878uwpgvh8.fsf@web.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 15900 Cc: 15900@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > CCing Drew cause the Change Log mentions him with regard to > `foreground-color-at-point'. Thanks, Michael. I wasn't reading this thread. 1. Let me first butt in with this preliminary comment, having now diff'd the current code (as of an MS Windows snapshot from 11/12) against the Emacs 24.3 code (which is the same as what I submitted). I think it is a mistake to fudge `face-at-point' so that it returns a face named in the buffer. That is NOT at all "the face of the character after point", which is what the doc string first line says. And it is (was) not the intention of `face-at-point' at all. See below for a suggestion, for those who want a face named at point. In addition, that argument should not be called THING. It is NOT (as is usually the case for an argument so named) a symbol or a string naming an Emacs THING, as in `thingatpt.el'. It is just a Boolean which if non-nil means to try first for a face name at point. =20 IOW, it should be called something like CHECK-FOR-FACE-NAMED-IN-TEXT. 2. Now on to the addition of argument MULTIPLE, which is mainly what this bug is about, IIUC. In the bug report, Michael said this: it looks only at one face and disregards the others. This is especially meaningless when this first face doesn't specify any foreground at all. Yes, `face-at-point' returned only the first of a list of faces. No, it is not meaningless for `face-at-point' to return a face that does not specify a foreground. Or does not specify a background. Or an underline. Or any other face attribute. By default, it was designed to return face `default' if no other face was found at point but if another face was found it returned that face. `face-at-point' should give you a face at point, regardless of the attributes that face might specify explicitly. Does it make sense for `foreground-color-at-point' to return nil if the face returned by `face-at-point' specifies no foreground? Yes. It was designed to return the color specified by a given face, and if no such color was specified, to return nil. But it uses `face-at-point', which looks at face `default' if no other face is found at point. If there is a non-`default' face at point, then its foreground should be used, and if there is none, then nil should be the result. 3. But MULTIPLE is something else. It aims to give you all of the faces at point, whether used as a text property or an overlay property. Like THING, MULTIPLE was added after I contributed the code. But unlike THING, MULTIPLE is a good addition. I can imagine that it might be useful to optionally get only faces used as a text property or only those used as an overlay property. Michael's use case is apparently one such. Perhaps `*face-at-point' should provide an argument for this. (That would certainly be more useful than the THING argument, which has nothing to do with the properties at point.) It looks like there is a bug wrt the use of `get-char-property'. `get-char-property' itself always favors an overlay property over the same property used as a text property at the same position. Furthermore, this important part of the `get-char-property' behavior is not even mentioned in the doc string (it is mentioned in the Elisp manual). This DOC BUG should be the first thing to be fixed. Given this limitation, it seems that the right thing for `face-at-point' to do is to gather faces using both `get-text-property' and `get-overlay-property', and not `get-char-property'. And it might be good to add an argument that lets you specify one or the other of these or both. Given that fix, MULTIPLE should DTRT. And Michael should be have what he needs. 4. So I would propose the following: a. REMOVE the misnamed argument THING altogether. It does not belong in `face-at-point'. Create a function `face-named-at-point' that returns the face named at point. Anyone wanting the behavior of first-look-for-face-named-... would use (or (face-named-at-point...) (face-at-point...)). The time to make this change is NOW, before 24.4 is released. b. Add an optional argument TYPE, with a nil value meaning both overlay and text property. Possible values would be `overlay', `text', and nil. c. TYPE would be taken into account regardless of the value of MULTIPLE. For non-nil MULTIPLE the function would return a list of all faces at point, whether in overlays or the `face' text property. `face-at-point' would use `get-text-property' or `get-overlay-property', or both, and not `get-char-property'. > > As you later discovered, even (face-at-point nil t) doesn't > > do the job. Which doesn't surprise me a bit: this kind of > > things cannot be done reliably from Lisp I don't see any basis for saying that. See above. Sounds pretty straightforward in Lisp, to me. What am I missing? > > even at a price of the kind of obfuscated code that > > face-at-point and foreground-color-at-point use.=20 Care to back that up? Just where do you see obfuscation? > > It is much simpler to write a C primitive that simulates > > the display, then returns the resulting face at a given > > character position, a simple and straightforward task on > > the C level, something the display engine does all the > > time. Overengineering, IMO. Not needed for `face-at-point', that I can see. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 03:45:00 2013 Received: (at 15900) by debbugs.gnu.org; 16 Nov 2013 08:45:00 +0000 Received: from localhost ([127.0.0.1]:56613 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhbUx-0007R1-SL for submit@debbugs.gnu.org; Sat, 16 Nov 2013 03:45:00 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:52720) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhbUu-0007Qk-6i for 15900@debbugs.gnu.org; Sat, 16 Nov 2013 03:44:57 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MWC00J00L7HLY00@a-mtaout21.012.net.il> for 15900@debbugs.gnu.org; Sat, 16 Nov 2013 10:44:49 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MWC00JAULMOHW60@a-mtaout21.012.net.il>; Sat, 16 Nov 2013 10:44:49 +0200 (IST) Date: Sat, 16 Nov 2013 10:44:36 +0200 From: Eli Zaretskii Subject: Re: bug#15900: 24.3.50; foreground-color-at-point returns wrong results In-reply-to: <878uwpgvh8.fsf@web.de> X-012-Sender: halo1@inter.net.il To: Michael Heerdegen Message-id: <83y54ohh1n.fsf@gnu.org> References: <87siuyxvw7.fsf@web.de> <83li0qhxyl.fsf@gnu.org> <878uwpgvh8.fsf@web.de> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15900 Cc: 15900@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Michael Heerdegen > Cc: 15900@debbugs.gnu.org, Drew Adams > Date: Fri, 15 Nov 2013 23:18:11 +0100 > > > As you later discovered, even (face-at-point nil t) doesn't do the > > job. > > > > Which doesn't surprise me a bit: this kind of things cannot be done > > reliably from Lisp, even at a price of the kind of obfuscated code > > that face-at-point and foreground-color-at-point use. It is much > > simpler to write a C primitive that simulates the display, then > > returns the resulting face at a given character position, a simple and > > straightforward task on the C level, something the display engine does > > all the time. > > That sounds good. Can we just do that? For some value of "we", yes. If "we" includes me and you, then it will have to be you, as my plate is pretty much full these days, sorry. In my defense, I can tell that this should be a nice exercise for someone who wants to get accustomed to hacking the display engine, as it shouldn't be too hard, and there's abundant example code that does similar things. > > > P.S. Some background: I'm working on an addition to stripe-buffer.el > > > that changes the foreground color continuously, instead of changing the > > > background. This is for better readability. > > > > > > I want to keep the foreground colors already present, so that e.g. links > > > in w3m are still recognizable. Paragraphs in italic can be colored > > > OTOH. > > > > > > So, what I need is a reliable `foreground-color-at-point'. Tips and > > > alternatives welcome. > > > > Why can't you detect that a portion of text is covered by specific > > properties (e.g., one of a list of known properties), and leave those > > portions alone? > > What do you mean with "properties" - text and overlay properties? Yes. > If faces are among them, I still must figure out if one of these > faces changes the foreground. You can know them in advance, I think. Your example talks about links, which use a known face. I presume there are only a few faces that needs such a special treatment, which would make the list of them quite short. IOW, why not test against a known list of properties that you want to leave alone, instead of digging into their color? > If not, i.e., if a face e.g. just underlines, I do want to color the > text nevertheless. The face used by links is different not only in its underline, but also in its color. If you want links to remain instantly recognizable, you should probably keep their appearance intact wholesale, not just the underline, otherwise how would the user distinguish between a link and underlined text? > Probably I didn't understand what you meant. More probable that I didn't understand what you meant. Hopefully the above tells enough about my misunderstanding to allow you to correct me. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 03:57:23 2013 Received: (at 15900) by debbugs.gnu.org; 16 Nov 2013 08:57:23 +0000 Received: from localhost ([127.0.0.1]:56627 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vhbgw-0007kZ-Lx for submit@debbugs.gnu.org; Sat, 16 Nov 2013 03:57:23 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:41094) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vhbgu-0007kL-4Z for 15900@debbugs.gnu.org; Sat, 16 Nov 2013 03:57:21 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MWC00F00M72OK00@a-mtaout22.012.net.il> for 15900@debbugs.gnu.org; Sat, 16 Nov 2013 10:57:13 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MWC00FU8M7DBQA0@a-mtaout22.012.net.il>; Sat, 16 Nov 2013 10:57:13 +0200 (IST) Date: Sat, 16 Nov 2013 10:57:01 +0200 From: Eli Zaretskii Subject: Re: bug#15900: 24.3.50; foreground-color-at-point returns wrong results In-reply-to: X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83vbzshggy.fsf@gnu.org> References: <87siuyxvw7.fsf@web.de> <83li0qhxyl.fsf@gnu.org> <878uwpgvh8.fsf@web.de> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15900 Cc: michael_heerdegen@web.de, 15900@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Fri, 15 Nov 2013 16:26:15 -0800 (PST) > From: Drew Adams > Cc: 15900@debbugs.gnu.org > > > > As you later discovered, even (face-at-point nil t) doesn't > > > do the job. Which doesn't surprise me a bit: this kind of > > > things cannot be done reliably from Lisp > > I don't see any basis for saying that. See above. Sounds > pretty straightforward in Lisp, to me. What am I missing? You are missing the fact that only part of what the display engine does to compute the appearance of a given character on display is exposed to Lisp. > > > even at a price of the kind of obfuscated code that > > > face-at-point and foreground-color-at-point use. > > Care to back that up? Just where do you see obfuscation? Everywhere. I don't understand why that code does what it does, for starters. It looks to me as a series of kludges one upon another, with the sole purpose of outsmarting the display engine. These kinds of things should never be done in Lisp, because they all will look like that: complicated, fragile, and unreliable. > > > It is much simpler to write a C primitive that simulates > > > the display, then returns the resulting face at a given > > > character position, a simple and straightforward task on > > > the C level, something the display engine does all the > > > time. > > Overengineering, IMO. In my book, a simple and elegant solution is always better than a complex and inelegant one. That's the opposite of over-engineering. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 11:20:16 2013 Received: (at 15900) by debbugs.gnu.org; 16 Nov 2013 16:20:16 +0000 Received: from localhost ([127.0.0.1]:57337 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhibX-0003Lg-KX for submit@debbugs.gnu.org; Sat, 16 Nov 2013 11:20:16 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:18669) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhibT-0003LQ-GR for 15900@debbugs.gnu.org; Sat, 16 Nov 2013 11:20:12 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rAGGK33l015102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Nov 2013 16:20:05 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAGGK2hm003549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Nov 2013 16:20:03 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAGGK1QI009755; Sat, 16 Nov 2013 16:20:01 GMT MIME-Version: 1.0 Message-ID: <6bc49739-fae0-4688-a3cc-8bbbc2fe1c04@default> Date: Sat, 16 Nov 2013 08:20:01 -0800 (PST) From: Drew Adams To: Eli Zaretskii Subject: RE: bug#15900: 24.3.50; foreground-color-at-point returns wrong results References: <<87siuyxvw7.fsf@web.de>> <<83li0qhxyl.fsf@gnu.org>> <<878uwpgvh8.fsf@web.de>> <> <<83vbzshggy.fsf@gnu.org>> In-Reply-To: <<83vbzshggy.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 15900 Cc: michael_heerdegen@web.de, 15900@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > > > > As you later discovered, even (face-at-point nil t) doesn't > > > > do the job. Which doesn't surprise me a bit: this kind of > > > > things cannot be done reliably from Lisp > > > > I don't see any basis for saying that. See above. Sounds > > pretty straightforward in Lisp, to me. What am I missing? >=20 > You are missing the fact that only part of what the display engine > does to compute the appearance of a given character on display is > exposed to Lisp. Please be specific. Just what, in the current context, cannot be done? The point of `face-at-point' is to give Lisp code a face at point. Clearly Lisp code can have access only to faces that it can access! What else is needed here, for `face-at-point'? > > Just where do you see obfuscation? >=20 > Everywhere. I don't understand why that code does what it does, for > starters. It looks to me as a series of kludges one upon another, > with the sole purpose of outsmarting the display engine. =20 Generalities. What things? In what way do you think it is trying to outsmart the display engine? If you criticize the code, that's good - but please speak about it specifically. Otherwise, there is no way to know what you are talking about, and no one can learn anything other than the fact that you don't understand the code. > These kinds of things should never be done in Lisp, because they > all will look like that: complicated, fragile, and unreliable. What kinds of things? What things? Why should they, whatever they are "never be done in Lisp"? I ask you to point to something specific that is problematic, and you just reply "Everywhere" and "these things" and "should never be done". That's not constructive. Talk about obfuscation! > In my book, a simple and elegant solution is always better than a > complex and inelegant one. That's the opposite of over-engineering. No one would disagree with that first sentence. Just a platitude, unfortunately. Please explain what complexity and inelegance you perceive, so we all can learn, instead of just mouthing "obfuscation" "everywhere". And while you're at it, please describe the Lisp-level function(s) that you propose to provide in C. I have no doubt they will be useful - I am confident in you for that. My questions are about your problems with the code of `face-at-point', not about your ability to provide something useful to Lisp from C. I look forward to some real, helpful information about both. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 11:40:33 2013 Received: (at 15900) by debbugs.gnu.org; 16 Nov 2013 16:40:33 +0000 Received: from localhost ([127.0.0.1]:57367 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhivA-0003sx-Kd for submit@debbugs.gnu.org; Sat, 16 Nov 2013 11:40:33 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:57444) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vhiv5-0003sQ-F3 for 15900@debbugs.gnu.org; Sat, 16 Nov 2013 11:40:31 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MWD00I007KKWL00@a-mtaout22.012.net.il> for 15900@debbugs.gnu.org; Sat, 16 Nov 2013 18:40:20 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MWD00ISG7N6VC20@a-mtaout22.012.net.il>; Sat, 16 Nov 2013 18:40:18 +0200 (IST) Date: Sat, 16 Nov 2013 18:40:07 +0200 From: Eli Zaretskii Subject: Re: bug#15900: 24.3.50; foreground-color-at-point returns wrong results In-reply-to: <6bc49739-fae0-4688-a3cc-8bbbc2fe1c04@default> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83li0ogv14.fsf@gnu.org> References: <6bc49739-fae0-4688-a3cc-8bbbc2fe1c04@default> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15900 Cc: michael_heerdegen@web.de, 15900@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 16 Nov 2013 08:20:01 -0800 (PST) > From: Drew Adams > Cc: michael_heerdegen@web.de, 15900@debbugs.gnu.org > > > > > > As you later discovered, even (face-at-point nil t) doesn't > > > > > do the job. Which doesn't surprise me a bit: this kind of > > > > > things cannot be done reliably from Lisp > > > > > > I don't see any basis for saying that. See above. Sounds > > > pretty straightforward in Lisp, to me. What am I missing? > > > > You are missing the fact that only part of what the display engine > > does to compute the appearance of a given character on display is > > exposed to Lisp. > > Please be specific. Just what, in the current context, cannot > be done? What foreground-color-at-point tries to do. > The point of `face-at-point' is to give Lisp code a face at point. I wasn't talking about face-at-point (although it, too, has its measure of difficulties, as the face of a character can come from umpteen different sources). This discussion is about foreground-color-at-point. > Clearly Lisp code can have access only to faces that it can access! > What else is needed here, for `face-at-point'? I was not talking about face-at-point. > > > Just where do you see obfuscation? > > > > Everywhere. I don't understand why that code does what it does, for > > starters. It looks to me as a series of kludges one upon another, > > with the sole purpose of outsmarting the display engine. > > Generalities. What things? In what way do you think it is trying > to outsmart the display engine? It tries to second-guess what the display engine would do given the faces and overlays at or around point. It is much better to ask the display engine to provide that information directly. > > These kinds of things should never be done in Lisp, because they > > all will look like that: complicated, fragile, and unreliable. > > What kinds of things? What things? foreground-color-at-point, of course. > Why should they, whatever they are "never be done in Lisp"? Because, for the umpteenth time, Lisp code is not given enough information to do that. > please describe the Lisp-level function(s) that you propose to > provide in C foreground-color-at-point, obviously. Maybe also background-color-at-point, for symmetry. I would also propose face-at-point, but that's another discussion. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 12:47:42 2013 Received: (at 15900) by debbugs.gnu.org; 16 Nov 2013 17:47:42 +0000 Received: from localhost ([127.0.0.1]:57396 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhjyA-0005bC-60 for submit@debbugs.gnu.org; Sat, 16 Nov 2013 12:47:42 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:28376) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vhjy5-0005ai-Ul for 15900@debbugs.gnu.org; Sat, 16 Nov 2013 12:47:38 -0500 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rAGHlVAM002053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Nov 2013 17:47:31 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAGHlUPR029605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Nov 2013 17:47:30 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAGHlTVc029599; Sat, 16 Nov 2013 17:47:29 GMT MIME-Version: 1.0 Message-ID: Date: Sat, 16 Nov 2013 09:47:29 -0800 (PST) From: Drew Adams To: Eli Zaretskii Subject: RE: bug#15900: 24.3.50; foreground-color-at-point returns wrong results References: <<6bc49739-fae0-4688-a3cc-8bbbc2fe1c04@default>> <<83li0ogv14.fsf@gnu.org>> In-Reply-To: <<83li0ogv14.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 15900 Cc: michael_heerdegen@web.de, 15900@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > > Please be specific. Just what, in the current context, cannot > > be done? >=20 > What foreground-color-at-point tries to do. Please be specific. You have said nothing about it, so far. > > The point of `face-at-point' is to give Lisp code a face at point. >=20 > I wasn't talking about face-at-point (although it, too, has its > measure of difficulties, as the face of a character can come from > umpteen different sources). This discussion is about > foreground-color-at-point. Fine. Replace `face-at-point' with `foreground-at-point' in my questions to you: Please be specific about the `foreground-at-point' code. So far, you have said nothing concrete about it. > > > Everywhere. I don't understand why that code does what it does, > > > for starters. It looks to me as a series of kludges one upon > > > another, with the sole purpose of outsmarting the display engine. > > > > Generalities. What things? In what way do you think it is trying > > to outsmart the display engine? >=20 > It tries to second-guess what the display engine would do given the > faces and overlays at or around point. =20 How so? Please point to something in the code that you think "tries to second-guess what the display engine would do..." Stop hand-waving, please. > It is much better to ask the display engine to provide that > information directly. What information? Please point to specifics in the Lisp code. > > > These kinds of things should never be done in Lisp, because they > > > all will look like that: complicated, fragile, and unreliable. > > > > What kinds of things? What things? >=20 > foreground-color-at-point, of course. Again, just hand-waving. Just what things in the code of `foreground-color-at-point' are problematic, for you? > > Why should they, whatever they are, "never be done in Lisp"? >=20 > Because, for the umpteenth time, Lisp code is not given enough > information to do that. To do what? What information are you hinting about? Please stop with the generalities about "Lisp code" and "these kinds of things" and "information", and get down to Earth with your criticism of the `foreground-color-at-point' code. You claim that the code is obfuscated. I want to learn just how that is. What is unclear about it? > > please describe the Lisp-level function(s) that you propose to > > provide in C >=20 > foreground-color-at-point, obviously. I see. And what is the spec of what that function would do? What would it do differently? Just what is the problem you would be trying to solve by moving the implementation of this function to C? Please don't just reply that you will remove obfuscation or some such. Be specific about the problems you see in the Lisp code and how you will solve those problems by moving the code to C. I'm sure that if you do that I will understand, and will likely be convinced. But so far you have just been hand-waving, and its hard to learn anything from that. Clearly, if Lisp code cannot be used to accomplish something that C code can, then we want to that something in C. So far, you have said nothing about what that something is. Except for generalities: get the foreground color at point or some such. Speak about the specific differences, please. The lisp code for `foreground-color-at-point' uses `face-at-point' (which you say you don't see as the problem) and text properties `read-face-name' and `face'. That is the design - simple, and perhaps too simple for all purposes. But I don't see obfuscation there - it's pretty clear what is going on. It would be clearer perhaps if the doc string said explicitly that the foreground color returned, if any, is taken from `face-at-point' or text property `read-face-name' or `face', in that order. I'm certainly willing to believe that those three things will not always provide all possible information about the foreground color at point. But there is no confusion or hiding of just what the code does, IMO. It confuses me that you say the code is confusing, so I ask you, "How so?" If you become specific in this discussion then there might be some hope of light, instead of just smoke. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 13:18:44 2013 Received: (at 15900) by debbugs.gnu.org; 16 Nov 2013 18:18:44 +0000 Received: from localhost ([127.0.0.1]:57411 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhkSB-0006Lv-TL for submit@debbugs.gnu.org; Sat, 16 Nov 2013 13:18:44 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:43812) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhkS6-0006LW-MP for 15900@debbugs.gnu.org; Sat, 16 Nov 2013 13:18:42 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MWD00J00C41LO00@a-mtaout22.012.net.il> for 15900@debbugs.gnu.org; Sat, 16 Nov 2013 20:18:23 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MWD00JK1C6MAWB0@a-mtaout22.012.net.il>; Sat, 16 Nov 2013 20:18:23 +0200 (IST) Date: Sat, 16 Nov 2013 20:18:12 +0200 From: Eli Zaretskii Subject: Re: bug#15900: 24.3.50; foreground-color-at-point returns wrong results In-reply-to: X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83iovsgqhn.fsf@gnu.org> References: X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15900 Cc: michael_heerdegen@web.de, 15900@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 16 Nov 2013 09:47:29 -0800 (PST) > From: Drew Adams > Cc: michael_heerdegen@web.de, 15900@debbugs.gnu.org > > > > Please be specific. Just what, in the current context, cannot > > > be done? > > > > What foreground-color-at-point tries to do. > > Please be specific. This is silly. You do know the purpose of foreground-color-at-point, don't you? Here's a scoop in case you didn't: it's trying to return the foreground color of the character at point. This is what I say cannot be reliably done in Lisp: you cannot reliably determine the colors of any specific character at any specific buffer position. Now, how more specific than that can one be?? > > It is much better to ask the display engine to provide that > > information directly. > > What information? The color of the character at point, of course. > > > please describe the Lisp-level function(s) that you propose to > > > provide in C > > > > foreground-color-at-point, obviously. > > I see. And what is the spec of what that function would do? Same one as the Lisp implementation, except that it will do that correctly and reliably. IOW, the implementation will change completely, while the API will remain unchanged, and the contract will also remain unchanged, except that it will now be always honored. > What would it do differently? It would simulate the display, as if Emacs actually did display the character at point, and return the color produced by that. You cannot do that in Lisp. > Just what is the problem you would be trying to solve by moving the > implementation of this function to C? The current Lisp code collects face information at or around point, and tries to deduce from that how the character will be displayed. Instead, the C implementation will actually display it (without putting the result on the glass). The result is guaranteed to be correct. By contrast, the Lisp implementation cannot promise such correctness, because it in effect tries to reproduce the logic used by the display engine, and the result is a different implementation, that cannot possibly be 100% compatible with what the display does. > I'm sure that if you do that I will understand, and will likely be > convinced. But so far you have just been hand-waving, and its > hard to learn anything from that. There's a lot of experience in hacking the display engine behind that hand-waving, so you may wish to accept what I'm saying. Or not, I really don't care much. > Clearly, if Lisp code cannot be used to accomplish something that > C code can, then we want to that something in C. So far, you have > said nothing about what that something is. Except for generalities: > get the foreground color at point or some such. Speak about the > specific differences, please. I can't: you lack too much knowledge for me to discuss the details. Just read xdisp.c, if you really want to know. I assure you that once you've done that, it will become crystal clear to you that producing the color at point is almost trivial on the C level, since code that simulates display is readily available and widely used by many Emacs features. Reimplementing that in Lisp is waste of energy. > The lisp code for `foreground-color-at-point' uses `face-at-point' > (which you say you don't see as the problem) and text properties > `read-face-name' and `face'. That is the design - simple, and > perhaps too simple for all purposes. Except that a face of a character can come from many different places, and there could be several different faces in effect at a given buffer position, some coming from text properties, others from overlays, still others from display strings, etc. etc. And what if the character at point is not even displayed, e.g. if it's covered by some invisibility spec? Why try to untangle all this complexity, when the display engine already does? > But I don't see obfuscation there - it's pretty clear what is > going on. It's wrong, for starters -- this is why this discussion started. And it's nowhere near clear, either; but I'm not going to try to convince you in that. > It would be clearer perhaps if the doc string said explicitly that > the foreground color returned, if any, is taken from `face-at-point' > or text property `read-face-name' or `face', in that order. As a user of this API, I don't really care. I want to know the foreground color of the character at point, and I don't care how the implementation does that. So any clarifications in the doc string about implementation details will not help me, as a user, to understand the answer to a simple question: does this API produce what it promises, or doesn't it? > I'm certainly willing to believe that those three things will not > always provide all possible information about the foreground > color at point. I'm trying to explain that you shouldn't even _try_ doing that in Lisp. If you do, you will just waste effort, and likely come up with unreliable results, because what the display engine does cannot be reliably reimplemented in Lisp, not with the current design. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 17:53:20 2013 Received: (at 15900) by debbugs.gnu.org; 16 Nov 2013 22:53:20 +0000 Received: from localhost ([127.0.0.1]:57581 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vhojw-0005zH-1n for submit@debbugs.gnu.org; Sat, 16 Nov 2013 17:53:20 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:20075) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vhojt-0005z3-Lw for 15900@debbugs.gnu.org; Sat, 16 Nov 2013 17:53:18 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rAGMrAwX000650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Nov 2013 22:53:11 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAGMr9Mo003391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Nov 2013 22:53:10 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAGMr9iB003388; Sat, 16 Nov 2013 22:53:09 GMT MIME-Version: 1.0 Message-ID: Date: Sat, 16 Nov 2013 14:53:09 -0800 (PST) From: Drew Adams To: Eli Zaretskii Subject: RE: bug#15900: 24.3.50; foreground-color-at-point returns wrong results References: <> <<83iovsgqhn.fsf@gnu.org>> In-Reply-To: <<83iovsgqhn.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 15900 Cc: michael_heerdegen@web.de, 15900@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Fair enough. Now you've made clear the intent. Thank you for the effort. I agree that it would be worthwhile to have the true foreground color at point, and not just the foreground color of a face at point. Looking forward to it. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 21:33:57 2013 Received: (at 15900) by debbugs.gnu.org; 17 Nov 2013 02:33:57 +0000 Received: from localhost ([127.0.0.1]:57704 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhsBR-0002zF-E9 for submit@debbugs.gnu.org; Sat, 16 Nov 2013 21:33:57 -0500 Received: from mout.web.de ([212.227.15.4]:61727) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhsBP-0002z1-BT for 15900@debbugs.gnu.org; Sat, 16 Nov 2013 21:33:56 -0500 Received: from drachen.dragon ([90.186.41.197]) by smtp.web.de (mrweb103) with ESMTPA (Nemesis) id 0MJl1M-1Viyds3SqK-0019g3 for <15900@debbugs.gnu.org>; Sun, 17 Nov 2013 03:33:49 +0100 From: Michael Heerdegen To: Eli Zaretskii Subject: Re: bug#15900: 24.3.50; foreground-color-at-point returns wrong results References: <87siuyxvw7.fsf@web.de> <83li0qhxyl.fsf@gnu.org> <878uwpgvh8.fsf@web.de> <83y54ohh1n.fsf@gnu.org> Date: Sun, 17 Nov 2013 03:33:47 +0100 In-Reply-To: <83y54ohh1n.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 16 Nov 2013 10:44:36 +0200") Message-ID: <87siuv21v8.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:LWXMMHRIJEggbEurIpzMhc6ONv5jksPajRvAXvvxRXJ1TnKwYnf PlZUt/I5v2e/bicNu2p5YveVhixiI2cv+T1jldKbbtMDvhiNmVTW7zOa79cSYKbNhUIrX03 lFrO0tMKv7w1GxHmrkFIooputW6ec+RmR3SsIX+oRMikjaKTtA5lnNfrTU/RozZQzYW61ac 9rxbZcliaNSkUAz7DozcQ== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 15900 Cc: 15900@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: > > That sounds good. Can we just do that? > > For some value of "we", yes. If "we" includes me and you, then it > will have to be you, as my plate is pretty much full these days, > sorry. In my defense, I can tell that this should be a nice exercise > for someone who wants to get accustomed to hacking the display engine, > as it shouldn't be too hard, and there's abundant example code that > does similar things. Sorry Eli, but I can't do it. I'm a real noob to C. > > If faces are among them, I still must figure out if one of these > > faces changes the foreground. > > You can know them in advance, I think. Your example talks about > links, which use a known face. I presume there are only a few faces > that needs such a special treatment, which would make the list of them > quite short. > > IOW, why not test against a known list of properties that you want to > leave alone, instead of digging into their color? I think the missing information you didn't have is that this is a general mode, it must work in any Emacs buffer. w3m was only an example - info, man, and gnus are others. So, testing for hardcoded face or property lists is not really an option. > > If not, i.e., if a face e.g. just underlines, I do want to color the > > text nevertheless. > > The face used by links is different not only in its underline, but > also in its color. If you want links to remain instantly > recognizable, you should probably keep their appearance intact > wholesale, not just the underline, otherwise how would the user > distinguish between a link and underlined text? Yes, that's what I actually do ;-) > > Probably I didn't understand what you meant. > > More probable that I didn't understand what you meant. Hopefully the > above tells enough about my misunderstanding to allow you to correct > me. I think that you thought that what I do is w3m specific, but it's not. It should work in any buffer, with any modes. And it should change the foreground color for every piece of text that has the default foreground color. Thanks, and regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 22:52:53 2013 Received: (at 15900) by debbugs.gnu.org; 17 Nov 2013 03:52:53 +0000 Received: from localhost ([127.0.0.1]:57766 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhtPp-00056O-8r for submit@debbugs.gnu.org; Sat, 16 Nov 2013 22:52:53 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:59508) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhtPm-000568-5U for 15900@debbugs.gnu.org; Sat, 16 Nov 2013 22:52:52 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MWE00M002G2CW00@a-mtaout20.012.net.il> for 15900@debbugs.gnu.org; Sun, 17 Nov 2013 05:52:43 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MWE00M802RUBZ30@a-mtaout20.012.net.il>; Sun, 17 Nov 2013 05:52:43 +0200 (IST) Date: Sun, 17 Nov 2013 05:52:33 +0200 From: Eli Zaretskii Subject: Re: bug#15900: 24.3.50; foreground-color-at-point returns wrong results In-reply-to: <87siuv21v8.fsf@web.de> X-012-Sender: halo1@inter.net.il To: Michael Heerdegen Message-id: <83eh6fhegu.fsf@gnu.org> References: <87siuyxvw7.fsf@web.de> <83li0qhxyl.fsf@gnu.org> <878uwpgvh8.fsf@web.de> <83y54ohh1n.fsf@gnu.org> <87siuv21v8.fsf@web.de> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15900 Cc: 15900@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Michael Heerdegen > Cc: 15900@debbugs.gnu.org, drew.adams@oracle.com > Date: Sun, 17 Nov 2013 03:33:47 +0100 > > > > If faces are among them, I still must figure out if one of these > > > faces changes the foreground. > > > > You can know them in advance, I think. Your example talks about > > links, which use a known face. I presume there are only a few faces > > that needs such a special treatment, which would make the list of them > > quite short. > > > > IOW, why not test against a known list of properties that you want to > > leave alone, instead of digging into their color? > > I think the missing information you didn't have is that this is a > general mode, it must work in any Emacs buffer. w3m was only an example > - info, man, and gnus are others. So, testing for hardcoded face or > property lists is not really an option. I still don't see why it isn't an option, even for a general-purpose mode. The list of faces that need such special treatment must be quite short, and it can be a defcustom. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 17 00:35:17 2013 Received: (at 15900) by debbugs.gnu.org; 17 Nov 2013 05:35:17 +0000 Received: from localhost ([127.0.0.1]:57858 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vhv0v-0007ZR-AN for submit@debbugs.gnu.org; Sun, 17 Nov 2013 00:35:17 -0500 Received: from mout.web.de ([212.227.17.11]:51350) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vhv0t-0007ZD-AL for 15900@debbugs.gnu.org; Sun, 17 Nov 2013 00:35:16 -0500 Received: from drachen.dragon ([90.186.41.197]) by smtp.web.de (mrweb102) with ESMTPA (Nemesis) id 0M0yiR-1VQ7PQ03BP-00v6Z9 for <15900@debbugs.gnu.org>; Sun, 17 Nov 2013 06:35:08 +0100 From: Michael Heerdegen To: Eli Zaretskii Subject: Re: bug#15900: 24.3.50; foreground-color-at-point returns wrong results References: <87siuyxvw7.fsf@web.de> <83li0qhxyl.fsf@gnu.org> <878uwpgvh8.fsf@web.de> <83y54ohh1n.fsf@gnu.org> <87siuv21v8.fsf@web.de> <83eh6fhegu.fsf@gnu.org> Date: Sun, 17 Nov 2013 06:35:03 +0100 In-Reply-To: <83eh6fhegu.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 17 Nov 2013 05:52:33 +0200") Message-ID: <87eh6flhfc.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:607aWN4BB3DxEDxQ2mWO5Rh1tarbTtQ/7Ck7DkIa1405TDRXrmd P6ZzJawOZwuuH9atvice/4y9aheP9aqjkVmthKpNQ/iBlVFFVhNVoOIu16vk/bc7k55dR4H gPRtjHj4hwRgNGxA9xS2iHUrMzNhRpuFfB0SNJWf6GHLXQkfBi/TN5X9R1ii4geACDh4PBA pc3FG6y6sag6l+OPYaNdA== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 15900 Cc: 15900@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: > > > IOW, why not test against a known list of properties that you want to > > > leave alone, instead of digging into their color? > > > > I think the missing information you didn't have is that this is a > > general mode, it must work in any Emacs buffer. w3m was only an example > > - info, man, and gnus are others. So, testing for hardcoded face or > > property lists is not really an option. > > I still don't see why it isn't an option, even for a general-purpose > mode. The list of faces that need such special treatment must be > quite short, and it can be a defcustom. >From the user's point of view, yes, it's an option. But you mentioned it saying it would be easier to realize in Lisp. This is what I have: (cl-some (lambda (face) (not (memq (face-foreground face nil t) `(nil ,(face-attribute 'default :foreground) "unspecified-fg" "unspecified-bg")))) (cl-mapcan (lambda (face-or-list) (if (facep face-or-list) (list face-or-list) face-or-list)) (list (get-text-property (point) 'face) (get-text-property (point) 'font-lock-face)))) For your solution, I can use a different predicate, but would still have to find all faces at point, no? What do I miss? Regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 17 12:22:05 2013 Received: (at 15900) by debbugs.gnu.org; 17 Nov 2013 17:22:05 +0000 Received: from localhost ([127.0.0.1]:58870 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vi62u-0001nS-U1 for submit@debbugs.gnu.org; Sun, 17 Nov 2013 12:22:05 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:43052) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vi62s-0001mw-Ei for 15900@debbugs.gnu.org; Sun, 17 Nov 2013 12:22:03 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MWF0090041NA700@a-mtaout22.012.net.il> for 15900@debbugs.gnu.org; Sun, 17 Nov 2013 19:21:55 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MWF009RD48J6250@a-mtaout22.012.net.il>; Sun, 17 Nov 2013 19:21:55 +0200 (IST) Date: Sun, 17 Nov 2013 19:21:47 +0200 From: Eli Zaretskii Subject: Re: bug#15900: 24.3.50; foreground-color-at-point returns wrong results In-reply-to: <87eh6flhfc.fsf@web.de> X-012-Sender: halo1@inter.net.il To: Michael Heerdegen Message-id: <83d2lzgd04.fsf@gnu.org> References: <87siuyxvw7.fsf@web.de> <83li0qhxyl.fsf@gnu.org> <878uwpgvh8.fsf@web.de> <83y54ohh1n.fsf@gnu.org> <87siuv21v8.fsf@web.de> <83eh6fhegu.fsf@gnu.org> <87eh6flhfc.fsf@web.de> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15900 Cc: 15900@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Michael Heerdegen > Cc: 15900@debbugs.gnu.org, drew.adams@oracle.com > Date: Sun, 17 Nov 2013 06:35:03 +0100 > > For your solution, I can use a different predicate, but would still have > to find all faces at point, no? What do I miss? I don't know, and I don't know what am I missing, either. When you say "all the faces at point", what exactly do you mean by that? There can only be one 'face' text property at point, so do you mean faces that come from overlays? If that is what you mean, then why isn't get-char-property all you need to have your answer? I feel I'm missing something very basic here. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 17 12:30:11 2013 Received: (at 15900) by debbugs.gnu.org; 17 Nov 2013 17:30:11 +0000 Received: from localhost ([127.0.0.1]:58882 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vi6Aj-00020u-Rm for submit@debbugs.gnu.org; Sun, 17 Nov 2013 12:30:10 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:35452) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vi6Ag-0001zG-4z for 15900@debbugs.gnu.org; Sun, 17 Nov 2013 12:30:06 -0500 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rAHHTx97008481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 17 Nov 2013 17:30:00 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAHHTwAJ019803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Nov 2013 17:29:59 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rAHHTweI020094; Sun, 17 Nov 2013 17:29:58 GMT MIME-Version: 1.0 Message-ID: <69fed86b-8fdb-4563-88f5-715dc7fce1be@default> Date: Sun, 17 Nov 2013 09:29:57 -0800 (PST) From: Drew Adams To: Eli Zaretskii , Michael Heerdegen Subject: RE: bug#15900: 24.3.50; foreground-color-at-point returns wrong results References: <<87siuyxvw7.fsf@web.de>> <<83li0qhxyl.fsf@gnu.org>> <<878uwpgvh8.fsf@web.de>> <<83y54ohh1n.fsf@gnu.org>> <<87siuv21v8.fsf@web.de>> <<83eh6fhegu.fsf@gnu.org>> <<87eh6flhfc.fsf@web.de>> <<83d2lzgd04.fsf@gnu.org>> In-Reply-To: <<83d2lzgd04.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 15900 Cc: 15900@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) > > For your solution, I can use a different predicate, but would > > still have to find all faces at point, no? What do I miss? >=20 > I don't know, and I don't know what am I missing, either. >=20 > When you say "all the faces at point", what exactly do you mean by > that? There can only be one 'face' text property at point, so do > you mean faces that come from overlays? If that is what you mean, > then why isn't get-char-property all you need to have your answer? > I feel I'm missing something very basic here. I think he means that the value of property `face' (whether from a text property or an overlay property) can be a list of faces. Normally, the attributes of the faces in the list are merged for display. See (elisp) `Special Properties' and (elisp `Overlay Properties'. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 17 12:47:28 2013 Received: (at 15900) by debbugs.gnu.org; 17 Nov 2013 17:47:28 +0000 Received: from localhost ([127.0.0.1]:58889 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vi6RT-0002TZ-Nt for submit@debbugs.gnu.org; Sun, 17 Nov 2013 12:47:28 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:48565) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vi6RQ-0002TK-9x for 15900@debbugs.gnu.org; Sun, 17 Nov 2013 12:47:25 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MWF009005BUI300@a-mtaout22.012.net.il> for 15900@debbugs.gnu.org; Sun, 17 Nov 2013 19:47:18 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MWF009F15ET62A0@a-mtaout22.012.net.il>; Sun, 17 Nov 2013 19:47:18 +0200 (IST) Date: Sun, 17 Nov 2013 19:47:10 +0200 From: Eli Zaretskii Subject: Re: bug#15900: 24.3.50; foreground-color-at-point returns wrong results In-reply-to: <69fed86b-8fdb-4563-88f5-715dc7fce1be@default> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83bo1ihqe9.fsf@gnu.org> References: <69fed86b-8fdb-4563-88f5-715dc7fce1be@default> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15900 Cc: michael_heerdegen@web.de, 15900@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 17 Nov 2013 09:29:57 -0800 (PST) > From: Drew Adams > Cc: 15900@debbugs.gnu.org, drew.adams@oracle.com > > > When you say "all the faces at point", what exactly do you mean by > > that? There can only be one 'face' text property at point, so do > > you mean faces that come from overlays? If that is what you mean, > > then why isn't get-char-property all you need to have your answer? > > I feel I'm missing something very basic here. > > I think he means that the value of property `face' (whether from > a text property or an overlay property) can be a list of faces. Yes, but then you get all that list in a single call to get-char-property, right? So where's the difficulty in collecting "all the faces at point"? From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 17 17:38:28 2013 Received: (at 15900) by debbugs.gnu.org; 17 Nov 2013 22:38:28 +0000 Received: from localhost ([127.0.0.1]:59146 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ViAz6-0001RQ-3Z for submit@debbugs.gnu.org; Sun, 17 Nov 2013 17:38:28 -0500 Received: from mout.web.de ([212.227.15.4]:55873) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ViAz3-0001RC-ST for 15900@debbugs.gnu.org; Sun, 17 Nov 2013 17:38:26 -0500 Received: from drachen.dragon ([90.186.252.235]) by smtp.web.de (mrweb102) with ESMTPA (Nemesis) id 0LeLWz-1VKzmX1JMb-00qCiI for <15900@debbugs.gnu.org>; Sun, 17 Nov 2013 23:38:19 +0100 From: Michael Heerdegen To: Eli Zaretskii Subject: Re: bug#15900: 24.3.50; foreground-color-at-point returns wrong results References: <69fed86b-8fdb-4563-88f5-715dc7fce1be@default> <83bo1ihqe9.fsf@gnu.org> Date: Sun, 17 Nov 2013 23:38:11 +0100 In-Reply-To: <83bo1ihqe9.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 17 Nov 2013 19:47:10 +0200") Message-ID: <87a9h264do.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:KTezp4Pp/YL3CQTBgvkQiCRkJux15jgUEqnKV9tjpeHSdR3XZ5l kCkcOzFt6PEUp5oe48+9GwhjPl+zZbsq/cyHAf73OK+nXatEzWbpIsZZ+pUWCVcwmfjJaBK PyjU0j8W74U6lZgQJxCMOlpcasKqzb01H5wOdMnbD9raDN0SzZcqkw5PEV7TmyVM7wrq7n8 WZfl2mQDb/FVhko19ZiXA== X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 15900 Cc: 15900@debbugs.gnu.org, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) Hello, > > I think he means that the value of property `face' (whether from > > a text property or an overlay property) can be a list of faces. Indeed. Plus, I want to look at the font-lock-face property. > Yes, but then you get all that list in a single call to > get-char-property, right? So where's the difficulty in collecting > "all the faces at point"? There's no difficulty. Eli, did you ever read the code snip I had included? Here it is again: (cl-some (lambda (face) (not (memq (face-foreground face nil t) `(nil ,(face-attribute 'default :foreground) "unspecified-fg" "unspecified-bg")))) (cl-mapcan (lambda (face-or-list) (if (facep face-or-list) (list face-or-list) face-or-list)) (list (get-text-property (point) 'face) (get-text-property (point) 'font-lock-face)))) I think what you mean, and what I do in the code, are quite the same (except for the predicate maybe). I appreciate your help, but please tell me if the snipped is ok or if you mean something else, and if so, what. I've just the feeling that we to talk at cross-purposes. Thanks, Michael. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 17 22:42:32 2013 Received: (at 15900) by debbugs.gnu.org; 18 Nov 2013 03:42:32 +0000 Received: from localhost ([127.0.0.1]:59290 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ViFjM-0000dT-1D for submit@debbugs.gnu.org; Sun, 17 Nov 2013 22:42:32 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:48277) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ViFjG-0000d8-TG for 15900@debbugs.gnu.org; Sun, 17 Nov 2013 22:42:28 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MWF00700WNEY400@a-mtaout21.012.net.il> for 15900@debbugs.gnu.org; Mon, 18 Nov 2013 05:42:20 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MWF0078VWYJR9B0@a-mtaout21.012.net.il>; Mon, 18 Nov 2013 05:42:20 +0200 (IST) Date: Mon, 18 Nov 2013 05:42:13 +0200 From: Eli Zaretskii Subject: Re: bug#15900: 24.3.50; foreground-color-at-point returns wrong results In-reply-to: <87a9h264do.fsf@web.de> X-012-Sender: halo1@inter.net.il To: Michael Heerdegen Message-id: <8361rqgyui.fsf@gnu.org> References: <69fed86b-8fdb-4563-88f5-715dc7fce1be@default> <83bo1ihqe9.fsf@gnu.org> <87a9h264do.fsf@web.de> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15900 Cc: 15900@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Michael Heerdegen > Cc: Drew Adams , 15900@debbugs.gnu.org > Date: Sun, 17 Nov 2013 23:38:11 +0100 > > Hello, > > > > I think he means that the value of property `face' (whether from > > > a text property or an overlay property) can be a list of faces. > > Indeed. Plus, I want to look at the font-lock-face property. > > > Yes, but then you get all that list in a single call to > > get-char-property, right? So where's the difficulty in collecting > > "all the faces at point"? > > There's no difficulty. Then I don't understand why you still want to analyze colors instead of analyzing faces. This is what my suggestion boiled down to: instead of trying to figure out the foreground color of the text at point, just compare its face(s) with a list of known faces whose appearance you don't want to override. > Eli, did you ever read the code snip I had included? Of course, I did. But it still talks about colors, something I suggested to avoid. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 18 02:50:54 2013 Received: (at 15900) by debbugs.gnu.org; 18 Nov 2013 07:50:54 +0000 Received: from localhost ([127.0.0.1]:59428 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ViJbh-00073v-Nc for submit@debbugs.gnu.org; Mon, 18 Nov 2013 02:50:54 -0500 Received: from mout.web.de ([212.227.17.12]:53510) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ViJbe-00073f-D4 for 15900@debbugs.gnu.org; Mon, 18 Nov 2013 02:50:51 -0500 Received: from drachen.dragon ([90.186.252.235]) by smtp.web.de (mrweb004) with ESMTPA (Nemesis) id 0MJpnI-1VjPXD114G-001EOe for <15900@debbugs.gnu.org>; Mon, 18 Nov 2013 08:50:44 +0100 From: Michael Heerdegen To: Eli Zaretskii Subject: Re: bug#15900: 24.3.50; foreground-color-at-point returns wrong results References: <69fed86b-8fdb-4563-88f5-715dc7fce1be@default> <83bo1ihqe9.fsf@gnu.org> <87a9h264do.fsf@web.de> <8361rqgyui.fsf@gnu.org> Date: Mon, 18 Nov 2013 08:50:37 +0100 In-Reply-To: <8361rqgyui.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 18 Nov 2013 05:42:13 +0200") Message-ID: <87siuum9ma.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:19YUJef8lLhfaeLOHjwH97tyccL36n8wOyjtiFnZYZn/cuYL/Vh 3AjSJAb16TckWvCbijyYtW4rcccXRsmv6NxC8H/ATVVUAhaz8pzV3CMjoq3cFIxrNbhJKUu zSSi0+j5Zgrk2PGHxyGJ4a+kIKn6O/Ey0RgHz1+9atNtgJ8eV1VLCLM7a6yj0g6p185lyUC 7aCQ4jSPkCu2PNGAawKbg== X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 15900 Cc: 15900@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) Eli Zaretskii writes: > > There's no difficulty. > > Then I don't understand why you still want to analyze colors instead > of analyzing faces. This is what my suggestion boiled down to: > instead of trying to figure out the foreground color of the text at > point, just compare its face(s) with a list of known faces whose > appearance you don't want to override. Ok, I think now I understand your point. And I see that my approach has its difficulties: faces can be customized (a foreground attribute can be removed or added), faces can even be frame dependent, etc. What I do is just a heuristic. Mmh, let me think about it. Thanks for your opinion. Regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 22 09:30:52 2022 Received: (at 15900) by debbugs.gnu.org; 22 Apr 2022 13:30:52 +0000 Received: from localhost ([127.0.0.1]:52029 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhtN6-00033D-3Y for submit@debbugs.gnu.org; Fri, 22 Apr 2022 09:30:52 -0400 Received: from quimby.gnus.org ([95.216.78.240]:38770) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhtN4-0002wr-8a for 15900@debbugs.gnu.org; Fri, 22 Apr 2022 09:30:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=p9vfrr5T1MniII0aeZ+39QlINItdcVfzCeRkSLheyz8=; b=HFeej2YYrF28PVwLQ98P029Ir0 jczNKkDNQbMWEAJQPzqWY5l9hDmfIKa2uAejQeDuIcqhzwN8k33T+hMkdLQzJ2mETkBDs0rvxjN3O 5dawog9lL447WtDB5/syBhaBNYUlcB9eGpk3q4k85CEGHvvzhNRdsV88ztnQRYBsnxkI=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nhtMv-0006th-T0; Fri, 22 Apr 2022 15:30:44 +0200 From: Lars Ingebrigtsen To: Michael Heerdegen Subject: Re: bug#15900: 24.3.50; foreground-color-at-point returns wrong results References: <87siuyxvw7.fsf@web.de> X-Now-Playing: ELpH's _Protection_: "Untitled" Date: Fri, 22 Apr 2022 15:30:39 +0200 In-Reply-To: <87siuyxvw7.fsf@web.de> (Michael Heerdegen's message of "Fri, 15 Nov 2013 03:04:56 +0100") Message-ID: <87bkwtxn28.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Michael Heerdegen writes: > `foreground-color-at-point' doesn't return the expected result when > there are several faces at point present. > > For example, on the red subject in a Gnus article buffer, or on a blue > link in w [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 15900 Cc: 15900@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Michael Heerdegen writes: > `foreground-color-at-point' doesn't return the expected result when > there are several faces at point present. > > For example, on the red subject in a Gnus article buffer, or on a blue > link in w3m, it returns "black". Looking at the code, I see that > `foreground-color-at-point' uses > > (face-at-point) > > i.e., it looks only at one face and disregards the others. This is > especially meaningless when this first face doesn't specify any > foreground at all. It looks like this was fixed a couple years later in this commit: commit 7ccedcb486ee4e37da54dd82a8557c80616d9467 Author: Artur Malabarba AuthorDate: Fri Oct 30 15:00:37 2015 +0000 * lisp/faces.el: Refactor common code and fix a bug (faces--attribute-at-point): New function. Fix a bug when the face at point is a list of faces and the desired attribute is not on the first one. (foreground-color-at-point, background-color-at-point): Use it. And I've verified that (foreground-color-at-point) seems to return sensible results in the test cases in Emacs 29, so I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 22 09:30:59 2022 Received: (at control) by debbugs.gnu.org; 22 Apr 2022 13:31:00 +0000 Received: from localhost ([127.0.0.1]:52032 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhtND-00038x-MP for submit@debbugs.gnu.org; Fri, 22 Apr 2022 09:30:59 -0400 Received: from quimby.gnus.org ([95.216.78.240]:38784) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhtNC-00033i-77 for control@debbugs.gnu.org; Fri, 22 Apr 2022 09:30:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=N6QzKpQPvs5qAeksz1Z8lCdFFwMN+eEXwYt3PMwT3g0=; b=Kn7iSwQ6A91TKrwkgLKS61gBru +23dUCwm4Ip6O7rk7+JdpRA1kQV3tas6fvRLmXDzbcqT6lZrBdo/mr7GjjnlkuNSoVDNkitSOHLRs vsRqXve+ecIz/GVY6AndN/xv6U9NJ7kuJVe5yrJdVj5Kgt0beJkW+T7ThP3VyfpYpnbc=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nhtN4-0006tp-RG for control@debbugs.gnu.org; Fri, 22 Apr 2022 15:30:52 +0200 Date: Fri, 22 Apr 2022 15:30:48 +0200 Message-Id: <87a6cdxn1z.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #15900 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 15900 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 15900 quit From unknown Sun Jun 15 14:44:41 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 21 May 2022 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator