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 10:44:36 +0200 Message-ID: <83y54ohh1n.fsf@gnu.org> References: <87siuyxvw7.fsf@web.de> <83li0qhxyl.fsf@gnu.org> <878uwpgvh8.fsf@web.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1384591513 22524 80.91.229.3 (16 Nov 2013 08:45:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Nov 2013 08:45:13 +0000 (UTC) Cc: 15900@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Nov 16 09:45: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 1VhbVD-0002ke-P6 for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Nov 2013 09:45:16 +0100 Original-Received: from localhost ([::1]:35133 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhbVD-00064v-B8 for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Nov 2013 03:45:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50842) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhbV6-00064n-Rd for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 03:45:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VhbV1-0004ig-VD for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 03:45:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42594) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VhbV1-0004hJ-S6 for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 03:45:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VhbV1-0007Rb-1Z for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2013 03:45:03 -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 08:45: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.138459150028590 (code B ref 15900); Sat, 16 Nov 2013 08:45:02 +0000 Original-Received: (at 15900) by debbugs.gnu.org; 16 Nov 2013 08:45:00 +0000 Original-Received: from localhost ([127.0.0.1]:56613 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhbUx-0007R1-SL for submit@debbugs.gnu.org; Sat, 16 Nov 2013 03:45:00 -0500 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:52720) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VhbUu-0007Qk-6i for 15900@debbugs.gnu.org; Sat, 16 Nov 2013 03:44:57 -0500 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MWC00J00L7HLY00@a-mtaout21.012.net.il> for 15900@debbugs.gnu.org; Sat, 16 Nov 2013 10:44:49 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MWC00JAULMOHW60@a-mtaout21.012.net.il>; Sat, 16 Nov 2013 10:44:49 +0200 (IST) In-reply-to: <878uwpgvh8.fsf@web.de> 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:80629 Archived-At: > From: Michael Heerdegen > Cc: 15900@debbugs.gnu.org, Drew Adams > Date: Fri, 15 Nov 2013 23:18:11 +0100 > > > 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, even at a price of the kind of obfuscated code > > that face-at-point and foreground-color-at-point use. 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. > > That sounds good. Can we just do that? For some value of "we", yes. If "we" includes me and you, then it will have to be you, as my plate is pretty much full these days, sorry. In my defense, I can tell that this should be a nice exercise for someone who wants to get accustomed to hacking the display engine, as it shouldn't be too hard, and there's abundant example code that does similar things. > > > P.S. Some background: I'm working on an addition to stripe-buffer.el > > > that changes the foreground color continuously, instead of changing the > > > background. This is for better readability. > > > > > > I want to keep the foreground colors already present, so that e.g. links > > > in w3m are still recognizable. Paragraphs in italic can be colored > > > OTOH. > > > > > > So, what I need is a reliable `foreground-color-at-point'. Tips and > > > alternatives welcome. > > > > Why can't you detect that a portion of text is covered by specific > > properties (e.g., one of a list of known properties), and leave those > > portions alone? > > What do you mean with "properties" - text and overlay properties? Yes. > If faces are among them, I still must figure out if one of these > faces changes the foreground. You can know them in advance, I think. Your example talks about links, which use a known face. I presume there are only a few faces that needs such a special treatment, which would make the list of them quite short. IOW, why not test against a known list of properties that you want to leave alone, instead of digging into their color? > If not, i.e., if a face e.g. just underlines, I do want to color the > text nevertheless. The face used by links is different not only in its underline, but also in its color. If you want links to remain instantly recognizable, you should probably keep their appearance intact wholesale, not just the underline, otherwise how would the user distinguish between a link and underlined text? > Probably I didn't understand what you meant. More probable that I didn't understand what you meant. Hopefully the above tells enough about my misunderstanding to allow you to correct me.