all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Drew Adams <drew.adams@oracle.com>
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 18:40:07 +0200	[thread overview]
Message-ID: <83li0ogv14.fsf@gnu.org> (raw)
In-Reply-To: <6bc49739-fae0-4688-a3cc-8bbbc2fe1c04@default>

> Date: Sat, 16 Nov 2013 08:20:01 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: michael_heerdegen@web.de, 15900@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.





  reply	other threads:[~2013-11-16 16:40 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         ` bug#15900: 24.3.50; foreground-color-at-point returns wrong results Drew Adams
2013-11-16 16:40           ` Eli Zaretskii [this message]
     [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=83li0ogv14.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=15900@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    --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.