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 08:20:01 -0800 (PST) Message-ID: <6bc49739-fae0-4688-a3cc-8bbbc2fe1c04@default> References: <<87siuyxvw7.fsf@web.de>> <<83li0qhxyl.fsf@gnu.org>> <<878uwpgvh8.fsf@web.de>> <> <<83vbzshggy.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 1384618886 27595 80.91.229.3 (16 Nov 2013 16:21:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Nov 2013 16:21: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 17:21:28 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 1Vhici-0003Ha-Bj for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Nov 2013 17:21:28 +0100 Original-Received: from localhost ([::1]:36215 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vhich-0001go-Te for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Nov 2013 11:21:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34125) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhicW-0001Zw-B1 for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 11:21:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VhicJ-0005Yd-Ve for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 11:21:16 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43322) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhicJ-0005YZ-SD for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 11:21:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VhicJ-0003NJ-Au for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 11:21:03 -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 16:21:03 +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.138461881612881 (code B ref 15900); Sat, 16 Nov 2013 16:21:03 +0000 Original-Received: (at 15900) by debbugs.gnu.org; 16 Nov 2013 16:20:16 +0000 Original-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 Original-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 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 rAGGK33l015102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Nov 2013 16:20:05 GMT Original-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 Original-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 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)] 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:80645 Archived-At: > > > > 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.