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 09:47:29 -0800 (PST)	[thread overview]
Message-ID: <c18e0f8c-e172-497d-b572-69162d77132b@default> (raw)
In-Reply-To: <<83li0ogv14.fsf@gnu.org>>

> > Please be specific.  Just what, in the current context, cannot
> > be done?
> 
> What foreground-color-at-point tries to do.

Please be specific.  You have said nothing about it, so far.

> > 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.

Fine.  Replace `face-at-point' with `foreground-at-point' in my
questions to you: Please be specific about the `foreground-at-point'
code.  So far, you have said nothing concrete about it.

> > > 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.  

How so?  Please point to something in the code that you think "tries
to second-guess what the display engine would do..."  Stop
hand-waving, please.

> It is much better to ask the display engine to provide that
> information directly.

What information?  Please point to specifics in the Lisp 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?
> 
> foreground-color-at-point, of course.

Again, just hand-waving.  Just what things in the code of
`foreground-color-at-point' are problematic, for you?

> > 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.

To do what?  What information are you hinting about?

Please stop with the generalities about "Lisp code" and "these
kinds of things" and  "information", and get down to Earth with
your criticism of the `foreground-color-at-point' code.  You claim
that the code is obfuscated.  I want to learn just how that is.
What is unclear about it?

> > please describe the Lisp-level function(s) that you propose to
> > provide in C
> 
> foreground-color-at-point, obviously.

I see.  And what is the spec of what that function would do?
What would it do differently?  Just what is the problem you would
be trying to solve by moving the implementation of this function
to C?

Please don't just reply that you will remove obfuscation or some
such.  Be specific about the problems you see in the Lisp code
and how you will solve those problems by moving the code to C.

I'm sure that if you do that I will understand, and will likely be
convinced.  But so far you have just been hand-waving, and its
hard to learn anything from that.

Clearly, if Lisp code cannot be used to accomplish something that
C code can, then we want to that something in C.  So far, you have
said nothing about what that something is.  Except for generalities:
get the foreground color at point or some such.  Speak about the
specific differences, please.

The lisp code for `foreground-color-at-point' uses `face-at-point'
(which you say you don't see as the problem) and text properties
`read-face-name' and `face'.  That is the design - simple, and
perhaps too simple for all purposes.

But I don't see obfuscation there - it's pretty clear what is
going on.  It would be clearer perhaps if the doc string said
explicitly that the foreground color returned, if any, is taken
from `face-at-point' or text property `read-face-name' or `face',
in that order.

I'm certainly willing to believe that those three things will not
always provide all possible information about the foreground
color at point.  But there is no confusion or hiding of just what
the code does, IMO.  It confuses me that you say the code is
confusing, so I ask you, "How so?"

If you become specific in this discussion then there might be
some hope of light, instead of just smoke.





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

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<6bc49739-fae0-4688-a3cc-8bbbc2fe1c04@default>
     [not found] ` <<83li0ogv14.fsf@gnu.org>
2013-11-16 17:47   ` Drew Adams [this message]
2013-11-16 18:18     ` bug#15900: 24.3.50; foreground-color-at-point returns wrong results Eli Zaretskii
     [not found] <<c18e0f8c-e172-497d-b572-69162d77132b@default>
     [not found] ` <<83iovsgqhn.fsf@gnu.org>
2013-11-16 22:53   ` Drew Adams
     [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
2013-11-16 16:40           ` 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
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=c18e0f8c-e172-497d-b572-69162d77132b@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.