GNU bug report logs -
#15900
24.3.50; foreground-color-at-point returns wrong results
Previous Next
Full log
Message #11 received at 15900 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Date: Fri, 15 Nov 2013 03:04:56 +0100
>
> `foreground-color-at-point' doesn't return the expected result when
> there are several faces at point present.
>
> For example, on the red subject in a Gnus article buffer, or on a blue
> link in w3m, it returns "black". Looking at the code, I see that
> `foreground-color-at-point' uses
>
> (face-at-point)
>
> i.e., it looks only at one face and disregards the others. This is
> especially meaningless when this first face doesn't specify any
> foreground at all.
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.
> 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?
This bug report was last modified 3 years and 26 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.