bug#15900: 24.3.50; foreground-color-at-point returns wrong results

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@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?