[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: bug#15900: 24.3.50; foreground-color-at-point returns wrong results
Date: Fri, 15 Nov 2013 10:26:58 +0200

> From: Michael Heerdegen <address@hidden>
> 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

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
> 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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]