[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: |
Michael Heerdegen |
Subject: |
bug#15900: 24.3.50; foreground-color-at-point returns wrong results |
Date: |
Fri, 15 Nov 2013 23:18:11 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
Hello,
CCing Drew cause the Change Log mentions him with regard to
`foreground-color-at-point'.
Eli Zaretskii <eliz@gnu.org> writes:
> 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?
> > 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? If
faces are among them, I still must figure out if one of these faces
changes the foreground. If not, i.e., if a face e.g. just underlines, I
do want to color the text nevertheless. Probably I didn't understand
what you meant. This expression works ok for me:
--8<---------------cut here---------------start------------->8---
(cl-some
(lambda (face) (not (memq (face-foreground face nil t)
`(nil
,(face-attribute 'default :foreground)
"unspecified-fg" "unspecified-bg"))))
(cl-mapcan (lambda (face-or-list) (if (facep face-or-list)
(list face-or-list)
face-or-list))
(list
(get-text-property (point) 'face)
(get-text-property (point) 'font-lock-face))))
--8<---------------cut here---------------end--------------->8---
Overlays are not covered by this - which is not even necessary, because
overlays have priorities that can be controlled.
Thanks,
Michael.
- bug#15900: 24.3.50; foreground-color-at-point returns wrong results, Michael Heerdegen, 2013/11/14
- bug#15900: 24.3.50; foreground-color-at-point returns wrong results, Michael Heerdegen, 2013/11/14
- bug#15900: 24.3.50; foreground-color-at-point returns wrong results, Eli Zaretskii, 2013/11/15
- bug#15900: 24.3.50; foreground-color-at-point returns wrong results,
Michael Heerdegen <=
- bug#15900: 24.3.50; foreground-color-at-point returns wrong results, Drew Adams, 2013/11/15
- bug#15900: 24.3.50; foreground-color-at-point returns wrong results, Eli Zaretskii, 2013/11/16
- bug#15900: 24.3.50; foreground-color-at-point returns wrong results, Drew Adams, 2013/11/16
- bug#15900: 24.3.50; foreground-color-at-point returns wrong results, Eli Zaretskii, 2013/11/16
- bug#15900: 24.3.50; foreground-color-at-point returns wrong results, Drew Adams, 2013/11/16
- bug#15900: 24.3.50; foreground-color-at-point returns wrong results, Eli Zaretskii, 2013/11/16
- bug#15900: 24.3.50; foreground-color-at-point returns wrong results, Drew Adams, 2013/11/16
- bug#15900: 24.3.50; foreground-color-at-point returns wrong results, Eli Zaretskii, 2013/11/16
- bug#15900: 24.3.50; foreground-color-at-point returns wrong results, Michael Heerdegen, 2013/11/16
- bug#15900: 24.3.50; foreground-color-at-point returns wrong results, Eli Zaretskii, 2013/11/16