GNU bug report logs - #15900
24.3.50; foreground-color-at-point returns wrong results

Previous Next

Package: emacs;

Reported by: Michael Heerdegen <michael_heerdegen <at> web.de>

Date: Fri, 15 Nov 2013 02:06:01 UTC

Severity: minor

Found in version 24.3.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: michael_heerdegen <at> web.de, 15900 <at> debbugs.gnu.org
Subject: bug#15900: 24.3.50; foreground-color-at-point returns wrong results
Date: Sat, 16 Nov 2013 18:40:07 +0200
> Date: Sat, 16 Nov 2013 08:20:01 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: michael_heerdegen <at> web.de, 15900 <at> debbugs.gnu.org
> 
> > > > > 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
> > >
> > > I don't see any basis for saying that.  See above.  Sounds
> > > pretty straightforward in Lisp, to me.  What am I missing?
> > 
> > You are missing the fact that only part of what the display engine
> > does to compute the appearance of a given character on display is
> > exposed to Lisp.
> 
> Please be specific.  Just what, in the current context, cannot
> be done?

What foreground-color-at-point tries to do.

> The point of `face-at-point' is to give Lisp code a face at point.

I wasn't talking about face-at-point (although it, too, has its
measure of difficulties, as the face of a character can come from
umpteen different sources).  This discussion is about
foreground-color-at-point.

> Clearly Lisp code can have access only to faces that it can access!
> What else is needed here, for `face-at-point'?

I was not talking about face-at-point.

> > > Just where do you see obfuscation?
> > 
> > Everywhere.  I don't understand why that code does what it does, for
> > starters.  It looks to me as a series of kludges one upon another,
> > with the sole purpose of outsmarting the display engine.  
> 
> Generalities.  What things?  In what way do you think it is trying
> to outsmart the display engine?

It tries to second-guess what the display engine would do given the
faces and overlays at or around point.  It is much better to ask the
display engine to provide that information directly.

> > These kinds of things should never be done in Lisp, because they
> > all will look like that: complicated, fragile, and unreliable.
> 
> What kinds of things?  What things?

foreground-color-at-point, of course.

> Why should they, whatever they are "never be done in Lisp"?

Because, for the umpteenth time, Lisp code is not given enough
information to do that.

> please describe the Lisp-level function(s) that you propose to
> provide in C

foreground-color-at-point, obviously.  Maybe also
background-color-at-point, for symmetry.  I would also propose
face-at-point, but that's another discussion.




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.