bug#25890: `color-values` gives wrong value

[Drew Adams <drew.adams@oracle.com>]

> the problem is in hexrgb-int-to-hex.  It does this:
> 
>   (substring (format (concat "%0" (int-to-string nb-digits) "X") int)
>              (- nb-digits))
> 
> which assumes that the digits to be produced, if n in the %0nX format
> is too small and doesn't allow to produce all of them, are the
> least-significant digits of the number.

Correct.  Which is just what its doc string says:

 If INT is too large to be represented with NB-DIGITS, then the result
 is truncated from the left.  So, for example, INT=256 and NB-DIGITS=2
 returns \"00\", since the hex equivalent of 256 decimal is 100, which
 is more than 2 digits.

That doesn't claim that the result faithfully represents the decimal
input value.  It doesn't.  But neither would truncating from the
right represent it correctly.  The doc string just describes the
behavior, letting you know what the (inaccurate) return value is
in such a case.

Is there an advantage in truncating from the right?  If so,
what?  Can you show how you would use such "corrected" behavior
advantageously?  To my mind, neither kind of truncation gives
you anything useful, if what you need is to represent the same
number faithfully.

> It should instead produce the most-significant digits.

Why?  How would that be better?  If the decimal number is too
big for the allotted number of hex digits then it is just too big.

> IOW, when #FFFFFF is converted to 16-bit per color component, it
> should yield #FF00FF00FF00, not #FFFFFFFFFFFF.

Where do you see `hexrgb-int-to-hex' being used as (I guess) you
suppose?  Where do you see #FFFFFF "converted" to #FFFFFFFFFFFF
(let alone to #FF00FF00FF00).

Sorry, but I just do not understand what you're trying to say.

Are you perhaps thinking of using `hexrgb-int-to-hex' together
with `hexrgb-hex-to-int', to "convert" from 6 hex digits to 12?
In that case, the "conversion" would be from "FFFFFF" to
"000000FFFFFF", which is correct, I think:

(hexrgb-int-to-hex (hexrgb-hex-to-int "FFFFFF") 12) => "000000FFFFFF"

Or from 2 to 4 hex digits (since the function is used on each
color component separately):

(hexrgb-int-to-hex (hexrgb-hex-to-int "FF") 4) => "00FF"

Or for your "E0" example:

(hexrgb-int-to-hex (hexrgb-hex-to-int "E0") 4) => "00E0"

I don't see any "conversion" from "E0" to "E0E0" (or to "E000",
which is apparently what you suggest is called for).

Can you please relate your message, whatever it might be, back
to your initial statement that hexrgb 'produces "#FFFFFFFFE0E0"
instead of "#FFFFFFFFE000" for the color mentioned by the OP'.

AFAIK, the color mentioned by the OP was "light yellow".  Do
we agree so far?  (I asked this once, but got no reply.)

(And I asked what sexp using the hexrgb code you tried, but I
got no answer there either.)

I said that if you use (hexrgb-color-name-to-hex "light yellow")
which is what I'd hope you would use, you do get "#FFFFFFFFE0E0".
And I said that that is, AFAIK, correct, not incorrect.

You say (I think) that the correct hex value for "light yellow"
is, or should be, "#FFFFFFFFE000".  But you haven't said why you
think that.

The color values for "light yellow" are: (65535 65535 57568).
I asked if you thought those values are correct, but I got no
reply.

Let's assume they are correct (they are not from hexrgb code,
anyway).  If so, the question is how each of those color values
should be represented using 4 hex digits.  `hexrgb-int-to-hex'
returns "FFFF" for each of the first two and "E0E0" for the third.

I asked if you agreed that that is correct, and you said yes.
To me, that means that it is correct for the 12-digit hex code
for "light yellow" to be "#FFFFFFFFE0E0", which you apparently
do not agree with.

I get the impression that you are perhaps thinking that it is
about "converting" FFFFE0 (not "light yellow") to FFFFFFFFE0E0
or to FFFFFFFFE000.  If so, why do you think that, and where
do you see the hexrgb code doing any such "conversion"?

Sorry, but I just do not get your message.  Could you perhaps
show some code that points out the bug you think you have found?
Could you show (with code) how using `hexrgb-int-to-hex' for
"light yellow" or whatever gives the wrong hex representation?

Saying that `hexrgb-int-to-hex' truncates from the left (i.e.,
drops the MSB) just repeats what its doc string says.  It's not
a bug but the declared behavior.

If you see a _use_ of `hexrgb-int-to-hex' in hexrgb.el that
leads to incorrect results because of that (intended) behavior,
please point to it.

I'd like to correct a bug in hexrgb, but so far I haven't been
able to see what it is.

You apparently think that `hexrgb-int-to-hex' should truncate
from the right, i.e., drop the LSB, not the MSB, when the number
is too large to be represented by the given number of hex digits.

I don't see the advantage of that.  If the number is too large
then it is too large.  For an integer value of 256 you would, I
guess, prefer to see the hex representation "10" returned instead
of "00".  I don't see how that would help anything.

I think the question is how code makes _use_ of `hexrgb-int-to-hex'.
If the number to convert is too big for the number of hex digits
allowed then there is no way to represent the decimal number with
those few hex digits.  I don't see an advantage to truncating from
the right instead of the left.

Can you give an actual example, where you would use a version of
`hexrgb-int-to-hex' that is corrected according to you (presumably
truncating at the right), where you can usefully make use of the
return value?  IOW, supposing a corrected `hexrgb-int-to-hex',
how would you use it in a sexp to take advantage of the correction?

AFAICS, if the decimal value cannot be represented with so few hex
digits there is no sense in trying to use the result as if it
represented the same number.  But perhaps I'm missing something.