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


Message #26 received at 15900 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, 15900 <at> debbugs.gnu.org
Subject: RE: bug#15900: 24.3.50; foreground-color-at-point returns wrong
 results
Date: Sat, 16 Nov 2013 08:20:01 -0800 (PST)
> > > > 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?

The point of `face-at-point' is to give Lisp code a face at point.
Clearly Lisp code can have access only to faces that it can access!
What else is needed here, for `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?  If you criticize the code, that's
good - but please speak about it specifically.  Otherwise, there is
no way to know what you are talking about, and no one can learn
anything other than the fact that you don't understand the code.

> 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?  Why should they, whatever they
are "never be done in Lisp"?  I ask you to point to something
specific that is problematic, and you just reply "Everywhere" and
"these things" and "should never be done".  That's not constructive.
Talk about obfuscation!

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

No one would disagree with that first sentence.  Just a platitude,
unfortunately.  Please explain what complexity and inelegance you
perceive, so we all can learn, instead of just mouthing "obfuscation"
"everywhere".

And while you're at it, please describe the Lisp-level function(s)
that you propose to provide in C.  I have no doubt they will be
useful - I am confident in you for that.  My questions are about
your problems with the code of `face-at-point', not about your
ability to provide something useful to Lisp from C.  I look forward
to some real, helpful information about both.




This bug report was last modified 3 years and 27 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.