[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: Sat, 16 Nov 2013 10:57:01 +0200

> Date: Fri, 15 Nov 2013 16:26:15 -0800 (PST)
> From: Drew Adams <address@hidden>
> Cc: address@hidden
> > > 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.

reply via email to

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