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 20:18:12 +0200 Message-ID: <83iovsgqhn.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1384625953 2325 80.91.229.3 (16 Nov 2013 18:19:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Nov 2013 18:19: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 19:19:16 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 1VhkSh-0006yk-VD for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Nov 2013 19:19:16 +0100 Original-Received: from localhost ([::1]:36560 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhkSh-0007qo-GA for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Nov 2013 13:19:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51501) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhkSZ-0007oz-9K for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 13:19:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VhkSU-0004NU-4B for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 13:19:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43392) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhkSU-0004NP-0i for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 13:19:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VhkST-0006MV-Kc for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 13:19:01 -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 18:19:01 +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.138462592424428 (code B ref 15900); Sat, 16 Nov 2013 18:19:01 +0000 Original-Received: (at 15900) by debbugs.gnu.org; 16 Nov 2013 18:18:44 +0000 Original-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 Original-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 Original-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) Original-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) In-reply-to: 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:80656 Archived-At: > 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.