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 10:57:01 +0200
> Date: Fri, 15 Nov 2013 16:26:15 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 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.

> > > even at a price of the kind of obfuscated code that
> > > face-at-point and foreground-color-at-point use. 
> 
> Care to back that up?  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.  These kinds
of things should never be done in Lisp, because they all will look
like that: complicated, fragile, and unreliable.

> > > 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.
> 
> Overengineering, IMO.

In my book, a simple and elegant solution is always better than a
complex and inelegant one.  That's the opposite of over-engineering.




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.