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: Sat, 16 Nov 2013 09:47:29 -0800 (PST) Message-ID: References: <<6bc49739-fae0-4688-a3cc-8bbbc2fe1c04@default>> <<83li0ogv14.fsf@gnu.org>> 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 1384624106 15911 80.91.229.3 (16 Nov 2013 17:48:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Nov 2013 17:48:26 +0000 (UTC) Cc: michael_heerdegen@web.de, 15900@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Nov 16 18:48:27 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 1Vhjyq-00052h-0V for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Nov 2013 18:48:24 +0100 Original-Received: from localhost ([::1]:36487 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vhjyp-0002mo-Lr for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Nov 2013 12:48:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47673) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vhjyd-0002kb-7g for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 12:48:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VhjyU-0004pD-Ju for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 12:48:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43378) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhjyU-0004p9-H8 for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 12:48:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VhjyU-0005by-50 for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 12:48: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 17:48: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.138462406221530 (code B ref 15900); Sat, 16 Nov 2013 17:48:02 +0000 Original-Received: (at 15900) by debbugs.gnu.org; 16 Nov 2013 17:47:42 +0000 Original-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 Original-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 Original-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 Original-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 Original-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 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)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] 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:80654 Archived-At: > > 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.