From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#15900: 24.3.50; foreground-color-at-point returns wrong results Date: Sat, 16 Nov 2013 18:40:07 +0200 Message-ID: <83li0ogv14.fsf@gnu.org> References: <6bc49739-fae0-4688-a3cc-8bbbc2fe1c04@default> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1384620073 7072 80.91.229.3 (16 Nov 2013 16:41:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Nov 2013 16:41:13 +0000 (UTC) Cc: michael_heerdegen@web.de, 15900@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Nov 16 17:41:17 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 1Vhivr-0006eD-Sw for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Nov 2013 17:41:16 +0100 Original-Received: from localhost ([::1]:36264 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vhivr-0005um-8m for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Nov 2013 11:41:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39173) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vhivj-0005ug-W4 for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 11:41:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vhive-0003ZD-QR for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 11:41:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43348) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vhive-0003Z8-MY for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 11:41:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Vhive-0003tr-FF for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 11:41:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Nov 2013 16:41: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.138462003314944 (code B ref 15900); Sat, 16 Nov 2013 16:41:02 +0000 Original-Received: (at 15900) by debbugs.gnu.org; 16 Nov 2013 16:40:33 +0000 Original-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 Original-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 Original-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) Original-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) In-reply-to: <6bc49739-fae0-4688-a3cc-8bbbc2fe1c04@default> X-012-Sender: halo1@inter.net.il 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:80649 Archived-At: > 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.