From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#15900: 24.3.50; foreground-color-at-point returns wrong results Date: Fri, 15 Nov 2013 16:26:15 -0800 (PST) Message-ID: References: <87siuyxvw7.fsf@web.de> <83li0qhxyl.fsf@gnu.org> <878uwpgvh8.fsf@web.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1384561640 20217 80.91.229.3 (16 Nov 2013 00:27:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Nov 2013 00:27:20 +0000 (UTC) Cc: 15900@debbugs.gnu.org To: Michael Heerdegen , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Nov 16 01:27:23 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VhTjP-0005CU-Bb for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Nov 2013 01:27:23 +0100 Original-Received: from localhost ([::1]:34316 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhTjO-0007A0-P9 for geb-bug-gnu-emacs@m.gmane.org; Fri, 15 Nov 2013 19:27:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60181) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhTjD-00079H-LF for bug-gnu-emacs@gnu.org; Fri, 15 Nov 2013 19:27:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VhTj5-0000l6-1I for bug-gnu-emacs@gnu.org; Fri, 15 Nov 2013 19:27:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42331) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhTj4-0000l2-UH for bug-gnu-emacs@gnu.org; Fri, 15 Nov 2013 19:27:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VhTj4-0003H2-EC for bug-gnu-emacs@gnu.org; Fri, 15 Nov 2013 19:27:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Nov 2013 00:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15900 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15900-submit@debbugs.gnu.org id=B15900.138456158712538 (code B ref 15900); Sat, 16 Nov 2013 00:27:02 +0000 Original-Received: (at 15900) by debbugs.gnu.org; 16 Nov 2013 00:26:27 +0000 Original-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 Original-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 Original-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 Original-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 Original-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 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)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:80622 Archived-At: > 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.