bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#41544: 26.3; Possible incorrect results from color-distance


From: Eli Zaretskii
Subject: bug#41544: 26.3; Possible incorrect results from color-distance
Date: Sat, 06 Jun 2020 16:57:38 +0300

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Sat, 6 Jun 2020 15:29:31 +0200
> Cc: 41544@debbugs.gnu.org
> 
> 6 juni 2020 kl. 13.59 skrev Eli Zaretskii <eliz@gnu.org>:
> 
> > I have already pointed out the negative consequences: the fix you
> > proposed changes the behavior and return values of a low-level API
> > that is used in many places, both directly and indirectly. Thus, it
> > runs a high risk of producing bugs and breaking code that works well
> > enough now.
> 
> This is very speculative and hypothetical. Forgive me for being sceptical, 
> but can you come up with a concrete and realistic example of what you think 
> will break?

None at this time.  But bitter experience has taught me that they will
almost certainly come.  They always do.

> > My assumption is that making changes for purely academic and/or
> > aesthetic reasons is something that we should avoid.
> 
> That is a rather disparaging way of referring to fixes intended to make code 
> working as advertised. 

If the problem is that the documentation doesn't match the behavior,
it is much easier for me to agree to amend the documentation.  In this
case, I think a Lisp program that interprets the documentation too
literally is making a mistake, but I'm not opposed to make that
clearer in the docs.

> > I don't even understand what each paragraph above tries to say, and/or
> > with what argument of mine it attempts to argue.
> 
> You were saying that #ffffffffffff is as good an approximation as any other, 
> and I was showing that it's not.

Then I'm not convinced, sorry.

> > Specifically, what is there that is the current state of affairs, what
> > is that _should_be_ the state of affairs
> 
> The current state of affairs is that 'color-values' returns an incorrect 
> value in certain cases. This can be fixed by making the code simpler and more 
> robust.

We've made a full circle: I was talking about the effects on the
callers of color-values and color-name-to-rgb, and explicitly asked
that we don't limit ourselves to these functions alone.  If there are
no problems caused to the callers of these functions, then I think we
should leave the code alone.





reply via email to

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