all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: michael_heerdegen@web.de, 15900@debbugs.gnu.org
Subject: bug#15900: 24.3.50; foreground-color-at-point returns wrong results
Date: Sat, 16 Nov 2013 08:20:01 -0800 (PST)	[thread overview]
Message-ID: <6bc49739-fae0-4688-a3cc-8bbbc2fe1c04@default> (raw)
In-Reply-To: <<83vbzshggy.fsf@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?

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.





       reply	other threads:[~2013-11-16 16:20 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<87siuyxvw7.fsf@web.de>
     [not found] ` <<83li0qhxyl.fsf@gnu.org>
     [not found]   ` <<878uwpgvh8.fsf@web.de>
     [not found]     ` <<b0006d1c-b470-4297-a6d7-97d7ed118c28@default>
     [not found]       ` <<83vbzshggy.fsf@gnu.org>
2013-11-16 16:20         ` Drew Adams [this message]
2013-11-16 16:40           ` bug#15900: 24.3.50; foreground-color-at-point returns wrong results Eli Zaretskii
     [not found]     ` <<83y54ohh1n.fsf@gnu.org>
     [not found]       ` <<87siuv21v8.fsf@web.de>
     [not found]         ` <<83eh6fhegu.fsf@gnu.org>
     [not found]           ` <<87eh6flhfc.fsf@web.de>
     [not found]             ` <<83d2lzgd04.fsf@gnu.org>
2013-11-17 17:29               ` Drew Adams
2013-11-17 17:47                 ` Eli Zaretskii
2013-11-17 22:38                   ` Michael Heerdegen
2013-11-18  3:42                     ` Eli Zaretskii
2013-11-18  7:50                       ` Michael Heerdegen
     [not found] <<c18e0f8c-e172-497d-b572-69162d77132b@default>
     [not found] ` <<83iovsgqhn.fsf@gnu.org>
2013-11-16 22:53   ` Drew Adams
     [not found] <<6bc49739-fae0-4688-a3cc-8bbbc2fe1c04@default>
     [not found] ` <<83li0ogv14.fsf@gnu.org>
2013-11-16 17:47   ` Drew Adams
2013-11-16 18:18     ` Eli Zaretskii
2013-11-15  2:04 Michael Heerdegen
2013-11-15  2:47 ` Michael Heerdegen
2013-11-15  8:26 ` Eli Zaretskii
2013-11-15 22:18   ` Michael Heerdegen
2013-11-16  0:26     ` Drew Adams
2013-11-16  8:57       ` Eli Zaretskii
2013-11-16  8:44     ` Eli Zaretskii
2013-11-17  2:33       ` Michael Heerdegen
2013-11-17  3:52         ` Eli Zaretskii
2013-11-17  5:35           ` Michael Heerdegen
2013-11-17 17:21             ` Eli Zaretskii
2022-04-22 13:30 ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6bc49739-fae0-4688-a3cc-8bbbc2fe1c04@default \
    --to=drew.adams@oracle.com \
    --cc=15900@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=michael_heerdegen@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.