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

[Drew Adams]

> > > It should instead produce the most-significant digits.
> >
> > Why?
> 
> Because that's how colors are interpreted on X,

I think you misunderstand `hexrgb-int-to-hex'.  It does
no color interpretation at all.

It simply converts a decimal integer to a string of hex
digits of a given length.  If the prescribed length is
too short for the number then the returned string clearly
cannot represent the number accurately - as is documented.

The fact that too few digits cannot represent the number
is irrespective of whether those too few digits are MSB
or LSB.

It's up to code calling the function to DTRT wrt the
number of digits it passes, just as it is up to the
caller of `hexrgb-hex-to-int' to pass a hex string that
does not represent an integer larger than what Emacs
can handle.

Here, for instance, is how `hexrgb-increment-hex' checks
inputs to `hexrgb-int-to-hex' before it calls it:

 (<= (length (format (concat \"%X\") INT)) NB-DIGITS)

The doc makes all of this pretty clear, I think.

> which is where Emacs takes its ideas of how to
> process these specs.

Emacs interprets color specs.  hexrgb does not.

> See, for example, this man page:
> https://linux.die.net/man/3/xparsecolor
> (Emacs on X uses XParseColor internally in the
> implementation of color-values.)

I see nothing on that page that conflicts with the hexrgb code.
In particular, this quote describes the hexrgb behavior too:

  "the string ''#3a7'' is the same as ''#3000a0007000''

Same color represented by both patterns.

You use `hexrgb-int-to-hex' on each color component separately,
and the maximum integer input is 65535 - as documented.

(hexrgb-int-to-hex (hexrgb-hex-to-int "7000") 4 ) ==> "7000"
(hexrgb-int-to-hex (hexrgb-hex-to-int "7")    1 ) ==> "7"

It is Emacs, not hexrgb, that interprets such a hex value
as a color component.  And Emacs (correctly) interprets
the component "7" in "#3a7" the same as it interprets the
component "7000" in "#3000a0007000" - same color.

> If you do it differently, sooner or later the results will
> clash with what Emacs does, and yield subtly wrong values.

hexrgb does not "do it" at all.  hexrgb does not conflict
with anything shown on the page you cited.

> I will now bail out of this discussion.  I have nothing more
> to say about this issue.  If you don't want to change
> hexrgb.el, that's your prerogative.

I've been clear that I would LOVE to fix a bug, if you can
please point to one.  Show some code that uses hexrgb and
produces an incorrect result, for example.