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

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

[Rasmus]

Hi,

I try to get the color value of my background, "light yellow", with
color.el.  However, `color-values` from faces.el returns the wrong value.

  (color-values "#ffffff")      => (65280 65280 65280) ; The max values.
  (color-values "#ffffe0")      => (65280 65280 57344) ; Light yellow hex.
  (color-values "light yellow") => (65535 65535 57568) ; The potential bug.

That is the color value of "light yellow" exceeds the maximum value as
defined by the color values of white (cf. `color-rgb-to-hex').  This means
that the color.el functions won't work.

Is this a bug or because color-values isn't intended for "complicated"
names like "light yellow"?  Unfortunately, the C code is a bit
complicated, so I couldn't identify where the bug, if it is a bug, is
introduced.

Thanks,
Rasmus
 

In GNU Emacs 26.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.22.7)
 of 2017-02-10 built on W530
Repository revision: 2d284db5c9c5ff23269e2ec277f5348abdf1cd47
Windowing system distributor 'The X.Org Foundation', version 11.0.11901000
Recent messages:
Mark set [3 times]
Mark saved where search started
Type "q" in help window to restore its previous buffer.
uncompressing faces.el.gz...done
Note: file is write protected

Quit
Mark set [2 times]
Mark deactivated
Mark activated
 [2 times]
Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
 --with-sound=alsa --with-xft --with-modules --with-x-toolkit=gtk3
 --without-gconf --with-gsettings --with-xwidgets 'CFLAGS=-march=x86-64
 -mtune=generic -O2 -pipe -fstack-protector-strong
 --param=ssp-buffer-size=4' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY ACL
LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 MODULES XWIDGETS LIBSYSTEMD

Important settings:
  value of $LC_MONETARY: en_DK.UTF-8
  value of $LC_NUMERIC: en_DK.UTF-8
  value of $LC_TIME: en_DK.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-netsplit-mode: t
  erc-notifications-mode: t
  erc-match-mode: t
  erc-spelling-mode: t
  erc-services-mode: t
  erc-networks-mode: t
  erc-smiley-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  recentf-mode: t
  shell-dirtrack-mode: t
  nyan-mode: t
  paredit-mode: t
  checkdoc-minor-mode: t
  subword-mode: t
  rainbow-mode: t
  global-company-mode: t
  company-mode: t
  diff-auto-refine-mode: t
  ido-everywhere: t
  global-auto-revert-mode: t
  which-function-mode: t
  winner-mode: t
  delete-selection-mode: t
  show-paren-mode: t
  electric-pair-mode: t
  savehist-mode: t
  save-place-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  prettify-symbols-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  global-visual-line-mode: t
  visual-line-mode: t
  transient-mark-mode: t

Load-path shadows:
/home/rasmus/.emacs.d/lisp/git-annex hides /home/rasmus/.emacs.d/elpa/git-annex-20160215.1111/git-annex
/home/rasmus/.emacs.d/lisp/readline-complete hides /home/rasmus/.emacs.d/elpa/readline-complete-20150708.737/readline-complete
/home/rasmus/.emacs.d/lisp/showtip hides /home/rasmus/.emacs.d/elpa/showtip-20080329.1959/showtip
/home/rasmus/.emacs.d/lisp/htmlize hides /usr/share/emacs/site-lisp/org_contrib/lisp/htmlize
/home/rasmus/.emacs.d/lisp/abbrev hides /usr/share/emacs/26.0.50/lisp/abbrev
/usr/share/emacs/site-lisp/org/ox-odt hides /usr/share/emacs/26.0.50/lisp/org/ox-odt
/usr/share/emacs/site-lisp/org/ox-texinfo hides /usr/share/emacs/26.0.50/lisp/org/ox-texinfo
/usr/share/emacs/site-lisp/org/ox-publish hides /usr/share/emacs/26.0.50/lisp/org/ox-publish
/usr/share/emacs/site-lisp/org/ox-org hides /usr/share/emacs/26.0.50/lisp/org/ox-org
/usr/share/emacs/site-lisp/org/ox-man hides /usr/share/emacs/26.0.50/lisp/org/ox-man
/usr/share/emacs/site-lisp/org/ox-md hides /usr/share/emacs/26.0.50/lisp/org/ox-md
/usr/share/emacs/site-lisp/org/ox-latex hides /usr/share/emacs/26.0.50/lisp/org/ox-latex
/usr/share/emacs/site-lisp/org/ox-html hides /usr/share/emacs/26.0.50/lisp/org/ox-html
/usr/share/emacs/site-lisp/org/ox-icalendar hides /usr/share/emacs/26.0.50/lisp/org/ox-icalendar
/usr/share/emacs/site-lisp/org/ox-ascii hides /usr/share/emacs/26.0.50/lisp/org/ox-ascii
/usr/share/emacs/site-lisp/org/ox-beamer hides /usr/share/emacs/26.0.50/lisp/org/ox-beamer
/usr/share/emacs/site-lisp/org/ox hides /usr/share/emacs/26.0.50/lisp/org/ox
/usr/share/emacs/site-lisp/org/org-table hides /usr/share/emacs/26.0.50/lisp/org/org-table
/usr/share/emacs/site-lisp/org/org-w3m hides /usr/share/emacs/26.0.50/lisp/org/org-w3m
/usr/share/emacs/site-lisp/org/org-timer hides /usr/share/emacs/26.0.50/lisp/org/org-timer
/usr/share/emacs/site-lisp/org/org-mouse hides /usr/share/emacs/26.0.50/lisp/org/org-mouse
/usr/share/emacs/site-lisp/org/org-mobile hides /usr/share/emacs/26.0.50/lisp/org/org-mobile
/usr/share/emacs/site-lisp/org/org-rmail hides /usr/share/emacs/26.0.50/lisp/org/org-rmail
/usr/share/emacs/site-lisp/org/org-src hides /usr/share/emacs/26.0.50/lisp/org/org-src
/usr/share/emacs/site-lisp/org/org-protocol hides /usr/share/emacs/26.0.50/lisp/org/org-protocol
/usr/share/emacs/site-lisp/org/org-mhe hides /usr/share/emacs/26.0.50/lisp/org/org-mhe
/usr/share/emacs/site-lisp/org/org-plot hides /usr/share/emacs/26.0.50/lisp/org/org-plot
/usr/share/emacs/site-lisp/org/org-info hides /usr/share/emacs/26.0.50/lisp/org/org-info
/usr/share/emacs/site-lisp/org/org-irc hides /usr/share/emacs/26.0.50/lisp/org/org-irc
/usr/share/emacs/site-lisp/org/org-inlinetask hides /usr/share/emacs/26.0.50/lisp/org/org-inlinetask
/usr/share/emacs/site-lisp/org/org hides /usr/share/emacs/26.0.50/lisp/org/org
/usr/share/emacs/site-lisp/org/org-pcomplete hides /usr/share/emacs/26.0.50/lisp/org/org-pcomplete
/usr/share/emacs/site-lisp/org/org-indent hides /usr/share/emacs/26.0.50/lisp/org/org-indent
/usr/share/emacs/site-lisp/org/org-list hides /usr/share/emacs/26.0.50/lisp/org/org-list
/usr/share/emacs/site-lisp/org/org-macro hides /usr/share/emacs/26.0.50/lisp/org/org-macro
/usr/share/emacs/site-lisp/org/org-macs hides /usr/share/emacs/26.0.50/lisp/org/org-macs
/usr/share/emacs/site-lisp/org/org-id hides /usr/share/emacs/26.0.50/lisp/org/org-id
/usr/share/emacs/site-lisp/org/org-habit hides /usr/share/emacs/26.0.50/lisp/org/org-habit
/usr/share/emacs/site-lisp/org/org-feed hides /usr/share/emacs/26.0.50/lisp/org/org-feed
/usr/share/emacs/site-lisp/org/org-gnus hides /usr/share/emacs/26.0.50/lisp/org/org-gnus
/usr/share/emacs/site-lisp/org/org-eshell hides /usr/share/emacs/26.0.50/lisp/org/org-eshell
/usr/share/emacs/site-lisp/org/org-element hides /usr/share/emacs/26.0.50/lisp/org/org-element
/usr/share/emacs/site-lisp/org/org-docview hides /usr/share/emacs/26.0.50/lisp/org/org-docview
/usr/share/emacs/site-lisp/org/org-footnote hides /usr/share/emacs/26.0.50/lisp/org/org-footnote
/usr/share/emacs/site-lisp/org/org-ctags hides /usr/share/emacs/26.0.50/lisp/org/org-ctags
/usr/share/emacs/site-lisp/org/org-faces hides /usr/share/emacs/26.0.50/lisp/org/org-faces
/usr/share/emacs/site-lisp/org/org-datetree hides /usr/share/emacs/26.0.50/lisp/org/org-datetree
/usr/share/emacs/site-lisp/org/org-crypt hides /usr/share/emacs/26.0.50/lisp/org/org-crypt
/usr/share/emacs/site-lisp/org/org-entities hides /usr/share/emacs/26.0.50/lisp/org/org-entities
/usr/share/emacs/site-lisp/org/org-colview hides /usr/share/emacs/26.0.50/lisp/org/org-colview
/usr/share/emacs/site-lisp/org/org-clock hides /usr/share/emacs/26.0.50/lisp/org/org-clock
/usr/share/emacs/site-lisp/org/ob-fortran hides /usr/share/emacs/26.0.50/lisp/org/ob-fortran
/usr/share/emacs/site-lisp/org/org-agenda hides /usr/share/emacs/26.0.50/lisp/org/org-agenda
/usr/share/emacs/site-lisp/org/ob-C hides /usr/share/emacs/26.0.50/lisp/org/ob-C
/usr/share/emacs/site-lisp/org/org-compat hides /usr/share/emacs/26.0.50/lisp/org/org-compat
/usr/share/emacs/site-lisp/org/org-bibtex hides /usr/share/emacs/26.0.50/lisp/org/org-bibtex
/usr/share/emacs/site-lisp/org/org-attach hides /usr/share/emacs/26.0.50/lisp/org/org-attach
/usr/share/emacs/site-lisp/org/org-bbdb hides /usr/share/emacs/26.0.50/lisp/org/org-bbdb
/usr/share/emacs/site-lisp/org/org-capture hides /usr/share/emacs/26.0.50/lisp/org/org-capture
/usr/share/emacs/site-lisp/org/org-archive hides /usr/share/emacs/26.0.50/lisp/org/org-archive
/usr/share/emacs/site-lisp/org/ob-tangle hides /usr/share/emacs/26.0.50/lisp/org/ob-tangle
/usr/share/emacs/site-lisp/org/ob-sqlite hides /usr/share/emacs/26.0.50/lisp/org/ob-sqlite
/usr/share/emacs/site-lisp/org/ob-table hides /usr/share/emacs/26.0.50/lisp/org/ob-table
/usr/share/emacs/site-lisp/org/ob-sql hides /usr/share/emacs/26.0.50/lisp/org/ob-sql
/usr/share/emacs/site-lisp/org/ob-shen hides /usr/share/emacs/26.0.50/lisp/org/ob-shen
/usr/share/emacs/site-lisp/org/ob-screen hides /usr/share/emacs/26.0.50/lisp/org/ob-screen
/usr/share/emacs/site-lisp/org/ob-scala hides /usr/share/emacs/26.0.50/lisp/org/ob-scala
/usr/share/emacs/site-lisp/org/ob-scheme hides /usr/share/emacs/26.0.50/lisp/org/ob-scheme
/usr/share/emacs/site-lisp/org/ob-sass hides /usr/share/emacs/26.0.50/lisp/org/ob-sass
/usr/share/emacs/site-lisp/org/ob-R hides /usr/share/emacs/26.0.50/lisp/org/ob-R
/usr/share/emacs/site-lisp/org/ob-ruby hides /usr/share/emacs/26.0.50/lisp/org/ob-ruby
/usr/share/emacs/site-lisp/org/ob-ref hides /usr/share/emacs/26.0.50/lisp/org/ob-ref
/usr/share/emacs/site-lisp/org/ob-python hides /usr/share/emacs/26.0.50/lisp/org/ob-python
/usr/share/emacs/site-lisp/org/ob-picolisp hides /usr/share/emacs/26.0.50/lisp/org/ob-picolisp
/usr/share/emacs/site-lisp/org/ob-plantuml hides /usr/share/emacs/26.0.50/lisp/org/ob-plantuml
/usr/share/emacs/site-lisp/org/ob-ocaml hides /usr/share/emacs/26.0.50/lisp/org/ob-ocaml
/usr/share/emacs/site-lisp/org/ob-perl hides /usr/share/emacs/26.0.50/lisp/org/ob-perl
/usr/share/emacs/site-lisp/org/ob-org hides /usr/share/emacs/26.0.50/lisp/org/ob-org
/usr/share/emacs/site-lisp/org/ob-maxima hides /usr/share/emacs/26.0.50/lisp/org/ob-maxima
/usr/share/emacs/site-lisp/org/ob-octave hides /usr/share/emacs/26.0.50/lisp/org/ob-octave
/usr/share/emacs/site-lisp/org/ob-mscgen hides /usr/share/emacs/26.0.50/lisp/org/ob-mscgen
/usr/share/emacs/site-lisp/org/ob-matlab hides /usr/share/emacs/26.0.50/lisp/org/ob-matlab
/usr/share/emacs/site-lisp/org/ob-makefile hides /usr/share/emacs/26.0.50/lisp/org/ob-makefile
/usr/share/emacs/site-lisp/org/ob-lob hides /usr/share/emacs/26.0.50/lisp/org/ob-lob
/usr/share/emacs/site-lisp/org/ob-lisp hides /usr/share/emacs/26.0.50/lisp/org/ob-lisp
/usr/share/emacs/site-lisp/org/ob-ledger hides /usr/share/emacs/26.0.50/lisp/org/ob-ledger
/usr/share/emacs/site-lisp/org/ob-lilypond hides /usr/share/emacs/26.0.50/lisp/org/ob-lilypond
/usr/share/emacs/site-lisp/org/ob-latex hides /usr/share/emacs/26.0.50/lisp/org/ob-latex
/usr/share/emacs/site-lisp/org/ob-keys hides /usr/share/emacs/26.0.50/lisp/org/ob-keys
/usr/share/emacs/site-lisp/org/ob-js hides /usr/share/emacs/26.0.50/lisp/org/ob-js
/usr/share/emacs/site-lisp/org/ob-java hides /usr/share/emacs/26.0.50/lisp/org/ob-java
/usr/share/emacs/site-lisp/org/ob-haskell hides /usr/share/emacs/26.0.50/lisp/org/ob-haskell
/usr/share/emacs/site-lisp/org/ob-gnuplot hides /usr/share/emacs/26.0.50/lisp/org/ob-gnuplot
/usr/share/emacs/site-lisp/org/ob-io hides /usr/share/emacs/26.0.50/lisp/org/ob-io
/usr/share/emacs/site-lisp/org/ob-exp hides /usr/share/emacs/26.0.50/lisp/org/ob-exp
/usr/share/emacs/site-lisp/org/ob-eval hides /usr/share/emacs/26.0.50/lisp/org/ob-eval
/usr/share/emacs/site-lisp/org/ob-css hides /usr/share/emacs/26.0.50/lisp/org/ob-css
/usr/share/emacs/site-lisp/org/ob-emacs-lisp hides /usr/share/emacs/26.0.50/lisp/org/ob-emacs-lisp
/usr/share/emacs/site-lisp/org/ob hides /usr/share/emacs/26.0.50/lisp/org/ob
/usr/share/emacs/site-lisp/org/ob-ditaa hides /usr/share/emacs/26.0.50/lisp/org/ob-ditaa
/usr/share/emacs/site-lisp/org/ob-core hides /usr/share/emacs/26.0.50/lisp/org/ob-core
/usr/share/emacs/site-lisp/org/ob-dot hides /usr/share/emacs/26.0.50/lisp/org/ob-dot
/usr/share/emacs/site-lisp/org/ob-calc hides /usr/share/emacs/26.0.50/lisp/org/ob-calc
/usr/share/emacs/site-lisp/org/ob-clojure hides /usr/share/emacs/26.0.50/lisp/org/ob-clojure
/usr/share/emacs/site-lisp/org/ob-comint hides /usr/share/emacs/26.0.50/lisp/org/ob-comint
/usr/share/emacs/site-lisp/org/ob-asymptote hides /usr/share/emacs/26.0.50/lisp/org/ob-asymptote
/usr/share/emacs/site-lisp/org/ob-awk hides /usr/share/emacs/26.0.50/lisp/org/ob-awk
/usr/share/emacs/site-lisp/org/org-loaddefs hides /usr/share/emacs/26.0.50/lisp/org/org-loaddefs
/usr/share/emacs/site-lisp/org/org-version hides /usr/share/emacs/26.0.50/lisp/org/org-version
/usr/share/emacs/site-lisp/org/org-install hides /usr/share/emacs/26.0.50/lisp/org/org-install

Features:
(shadow bbdb-message quail footnote cookie1 emacsbug erc-list erc-menu
erc-join erc-ring erc-pcomplete erc-track erc-button erc-fill erc-stamp
erc-netsplit erc-desktop-notifications erc-match erc-spelling erc-services
erc-networks erc-goodies erc erc-backend erc-compat mule-diag edebug
cus-start cus-load find-dired grep compile ffap add-log debug
ido-completing-read+ smex misearch multi-isearch recentf tree-widget
eieio-opt speedbar sb-image ezimage dframe gnus-notifications gnus-fun
notifications dbus flow-fill org-table proced gnus-html url-queue help-fns
radix-tree mm-url shr svg xml dom browse-url url-http url-gw url-auth
gnus-gravatar gravatar url-cache url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf gnus-picon sort hi-lock
flyspell ox-odt rng-loc rng-uri rng-parse rng-match rng-dt rng-util
rng-pttrn nxml-parse nxml-ns nxml-enc xmltok nxml-util ox-icalendar
org-cite reftex-cite ox-koma-letter ox-beamer ox-ascii ox-html table
ox-latex ox-publish ox ispell face-remap cdlatex texmathp reftex
reftex-loaddefs reftex-vars org-rmail org-mhe org-irc org-info org-gnus
org-docview doc-view jka-compr image-mode org-bibtex bibtex org-bbdb
org-w3m org-element avl-tree org-inlinetask org-indent
org-location-google-maps org-agenda google-maps google-maps-static
url-util google-maps-geocode google-maps-base json map org org-macro
org-footnote org-pcomplete org-list org-faces org-entities noutline
outline org-version ob-calc calc-store calc-trail calc-ext calc
calc-loaddefs calc-macs ob-shell ob-awk ob-org ob-octave ob-python ob-C
ob-emacs-lisp ob-fortran cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs ob-latex ob-R ob ob-tangle
org-src ob-ref ob-lob ob-table ob-keys ob-exp ob-comint tramp tramp-compat
tramp-loaddefs trampver ucs-normalize readline-complete shell pcomplete
comint ob-core ob-eval org-compat org-macs org-loaddefs find-func da-cal
holidays hol-loaddefs cal-menu calendar cal-loaddefs smiley gnus-cite
mm-archive mail-extr gnus-async gnus-bcklg qp gnus-ml disp-table
gnus-topic hl-line cursor-sensor epa-file utf-7 network-stream nsm
starttls nnfolder bbdb-gnus bbdb-mua nnnil gnus-demon gnus-harvest
bbdb-com crm mailalias nnir bbdb bbdb-site timezone smtpmail-async
smtpmail sendmail async gnus-delay gnus-draft gnus-agent gnus-srvr
gnus-score score-mode nnvirtual nntp gnus-cache gnus-msg gnus-art mm-uu
mml2015 mm-view mml-smime smime dig mailcap gnus-sum nndraft nnmh
gnus-group gnus-undo gnus-start gnus-cloud nnimap tls gnutls utf7 netrc
parse-time gnus-spec nnmail gnus-int gnus-range mail-source message puny
git-annex cl dired-aux dired-x dired dired-loaddefs format-spec rfc822 mml
mml-sec epa derived epg mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader gnus-win nnoo gnus nnheader subr-x
gnus-util rmail rmail-loaddefs rfc2047 rfc2045 ietf-drums mail-utils
mm-util mail-prsvr wid-edit nyan-mode paredit checkdoc thingatpt cap-words
superword subword rainbow-mode ansi-color color company-oddmuse
company-keywords company-etags etags xref project company-gtags
company-dabbrev-code company-dabbrev company-files company-capf
company-cmake company-xcode company-clang company-semantic company-eclim
company-template company-css company-nxml company-bbdb company-c-headers
rx company vc-git diff-mode easy-mmode bookmark pp ido autorevert
filenotify which-func imenu winner ring server pinentry windmove delsel
time-date paren elec-pair savehist saveplace edmacro kmacro finder-inf
tex-site advice info package epg-config url-handlers url-parse auth-source
cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache url-vars seq
byte-opt gv bytecomp byte-compile cl-extra help-mode easymenu cconv
cl-loaddefs pcase cl-lib mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode
register page menu-bar rfn-eshadow isearch timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core term/tty-colors frame
cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese composite charscript
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule custom
widget hashtable-print-readable backquote dbusbind inotify dynamic-setting
system-font-setting font-render-setting xwidget-internal move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 992968 563427)
 (symbols 48 62565 1120)
 (miscs 40 5725 14030)
 (strings 32 191481 179682)
 (string-bytes 1 5919595)
 (vectors 16 96124)
 (vector-slots 8 2231231 290956)
 (floats 8 1324 9912)
 (intervals 56 13687 17259)
 (buffers 976 71))

-- 
Evidence suggests Snowden used a powerful tool called monospaced fonts

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

[Eli Zaretskii]

> From: Rasmus <rasmus@gmx.us>
> Date: Mon, 27 Feb 2017 15:05:46 +0100
> 
> I try to get the color value of my background, "light yellow", with
> color.el.  However, `color-values` from faces.el returns the wrong value.
> 
>   (color-values "#ffffff")      => (65280 65280 65280) ; The max values.

Are you sure?  What does the below produce?

   (color-values "#fffffffff")

>   (color-values "#ffffe0")      => (65280 65280 57344) ; Light yellow hex.
>   (color-values "light yellow") => (65535 65535 57568) ; The potential bug.

On my system, I get these results:

  (color-values "#ffffff")      => (65535 65535 65535)
  (color-values "#ffffe0")      => (65535 65535 57568)
  (color-values "light yellow") => (65535 65535 57568)

> That is the color value of "light yellow" exceeds the maximum value as
> defined by the color values of white (cf. `color-rgb-to-hex').  This means
> that the color.el functions won't work.

I think this means your color resolution is greater than 24 bits.  Or
maybe I don't understand how the above affects your code.

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

[Rasmus]

Hi Eli,

Eli Zaretskii <eliz@gnu.org> writes:

>> I try to get the color value of my background, "light yellow", with
>> color.el.  However, `color-values` from faces.el returns the wrong value.
>> 
>>   (color-values "#ffffff")      => (65280 65280 65280) ; The max values.
>
> Are you sure?
>
> What does the below produce?
>
>    (color-values "#fffffffff")

For that I get the right value:

    (color-values "#fffffffff") => (65520 65520 65520)
    (color-values "#ffffff")    => (65280 65280 65280)

>>   (color-values "#ffffe0")      => (65280 65280 57344) ; Light yellow hex.
>>   (color-values "light yellow") => (65535 65535 57568) ; The potential bug.
>
> On my system, I get these results:
>
>   (color-values "#ffffff")      => (65535 65535 65535)
>   (color-values "#ffffe0")      => (65535 65535 57568)
>   (color-values "light yellow") => (65535 65535 57568)

Which seems more reasonable.

>> That is the color value of "light yellow" exceeds the maximum value as
>> defined by the color values of white (cf. `color-rgb-to-hex').  This means
>> that the color.el functions won't work.
>
> I think this means your color resolution is greater than 24 bits.

Xorg tells me it's using 24 bits.

    $> xwininfo -root | grep Depth
    Depth: 24

> Or maybe I don't understand how the above affects your code.

I want to manipulate colors such as "light yellow" with color.el.  E.g.

    (set-frame-parameter (selected-frame) 'background-color
                         (color-darken-name "light yellow" 5))

This produces an "Undefined color" error because

    (color-darken-name "light yellow" 5) => "#100100c6".

This in turn points to `color-name-to-rgb', which uses (color-values
"#ffffff") as the denominator.  Because "#ffffff produces an RGB triplet
with smaller numbers than "light yellow", I get an RGB triple with
elements exceeding 1, which it shouldn't.

So an easy fix might be to use "#fffffffff" in `color-name-to-rgb', but
then I'd still not have equal color values for the white with and without
alpha...

    (equal (color-values "#fffffffff") (color-values "#ffffff")) => nil

Thus, I suggested that the error was in the C code in my initial report.
I hope this explains the problem I'm seeing better.

Thanks,
Rasmus

-- 
Even a three-legged dog has three good legs to lose

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

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> >   (color-values "#ffffff") => (65280 65280 65280) ; The max values.
>
> Are you sure?

FWIW, I see the same here; and we already have a bug report like this
one:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24273


Michael.

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

[Rasmus]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> >   (color-values "#ffffff") => (65280 65280 65280) ; The max values.
>>
>> Are you sure?
>
> FWIW, I see the same here; and we already have a bug report like this
> one:
>
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24273

Oh thanks.  (I didn't search as gmane search is still down).

I guess this bug can be closed.

Rasmus

-- 
⠠⠵

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

[Eli Zaretskii]

> From: Rasmus <rasmus@gmx.us>
> Cc: eliz@gnu.org, 25890@debbugs.gnu.org
> Date: Tue, 28 Feb 2017 10:44:22 +0100
> 
> Michael Heerdegen <michael_heerdegen@web.de> writes:
> 
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >> >   (color-values "#ffffff") => (65280 65280 65280) ; The max values.
> >>
> >> Are you sure?
> >
> > FWIW, I see the same here; and we already have a bug report like this
> > one:
> >
> >   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24273
> 
> Oh thanks.  (I didn't search as gmane search is still down).
> 
> I guess this bug can be closed.

I'd rather we fixed it.

I think there's a bug in color.el: it assumes that the #RGB notation
uses 24 bits, i.e. each component maxes out at 255.  But Emacs does
its color calculations based on 16-bit components, which max out at
65535, which is why #ffffff does NOT produce (65535 65535 65535), the
white color.  (We decided long ago to use 16-bit components because X
APIs such as XParseColor on some systems, including yours, work with
such components.)  IOW, #ffffff is parsed as #ff00ff00ff00, and that
is not "white".

So I think the patch below is what is needed to fix this problem.  Can
you try it?  (There's one user of the functions the patch changes,
shr-color.el, which will need to be adapted to the change, if we
decide to install it.)


--- lisp/color.el~0	2017-01-02 06:25:09.000000000 +0200
+++ lisp/color.el	2017-02-28 17:35:43.570586100 +0200
@@ -52,14 +52,14 @@
 If FRAME cannot display COLOR, return nil."
   ;; `colors-values' maximum value is either 65535 or 65280 depending on the
   ;; display system.  So we use a white conversion to get the max value.
-  (let ((valmax (float (car (color-values "#ffffff")))))
+  (let ((valmax (float (car (color-values "#ffffffffffff")))))
     (mapcar (lambda (x) (/ x valmax)) (color-values color frame))))
 
 (defun color-rgb-to-hex  (red green blue)
   "Return hexadecimal notation for the color RED GREEN BLUE.
 RED, GREEN, and BLUE should be numbers between 0.0 and 1.0, inclusive."
-  (format "#%02x%02x%02x"
-          (* red 255) (* green 255) (* blue 255)))
+  (format "#%04x%04x%04x"
+          (* red 65535) (* green 65535) (* blue 65535)))
 
 (defun color-complement (color-name)
   "Return the color that is the complement of COLOR-NAME.

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

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> So I think the patch below is what is needed to fix this problem.  Can
> you try it?  (There's one user of the functions the patch changes,
> shr-color.el, which will need to be adapted to the change, if we
> decide to install it.)
>
>
> --- lisp/color.el~0	2017-01-02 06:25:09.000000000 +0200
> +++ lisp/color.el	2017-02-28 17:35:43.570586100 +0200
> @@ -52,14 +52,14 @@
>  If FRAME cannot display COLOR, return nil."
>    ;; `colors-values' maximum value is either 65535 or 65280 depending on the
>    ;; display system.  So we use a white conversion to get the max value.
> -  (let ((valmax (float (car (color-values "#ffffff")))))
> +  (let ((valmax (float (car (color-values "#ffffffffffff")))))
>      (mapcar (lambda (x) (/ x valmax)) (color-values color frame))))
>  
>  (defun color-rgb-to-hex  (red green blue)
>    "Return hexadecimal notation for the color RED GREEN BLUE.
>  RED, GREEN, and BLUE should be numbers between 0.0 and 1.0, inclusive."
> -  (format "#%02x%02x%02x"
> -          (* red 255) (* green 255) (* blue 255)))
> +  (format "#%04x%04x%04x"
> +          (* red 65535) (* green 65535) (* blue 65535)))
>  
>  (defun color-complement (color-name)
>    "Return the color that is the complement of COLOR-NAME.

With that patch, for me in the recipe of bug #24273, it makes a
difference; now

(color-name-to-rgb "#ffffff")
==>
(0.9961089494163424 0.9961089494163424 0.9961089494163424)

and

(color-name-to-rgb "white")
==>
(1.0 1.0 1.0)


For the recipe of this bug report, the values are the same as without
the patch.

I guess this is what you expected.  But is it ok that "#ffffff" is not
equivalent to "white"?  If it is, seems there is no inconsistency left.


Thanks so far,

Michael.

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

[Drew Adams]

> >  (defun color-rgb-to-hex  (red green blue)
> >    "Return hexadecimal notation for the color RED GREEN BLUE.
> >  RED, GREEN, and BLUE should be numbers between 0.0 and 1.0, inclusive."
> > -  (format "#%02x%02x%02x"
> > -          (* red 255) (* green 255) (* blue 255)))
> > +  (format "#%04x%04x%04x"
> > +          (* red 65535) (* green 65535) (* blue 65535)))

The function should accept an optional arg NB-DIGITS, which
specifies the number of hex digits for each of R, G, B.  And
yes, it should default to 4 digits: #RRRRGGGGBBBB.

(That's what the original function in hexrgb.el does, from
which color.el was supposedly derived.)

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

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: Rasmus <rasmus@gmx.us>,  25890@debbugs.gnu.org
> Date: Wed, 01 Mar 2017 00:42:02 +0100
> 
> With that patch, for me in the recipe of bug #24273, it makes a
> difference; now
> 
> (color-name-to-rgb "#ffffff")
> ==>
> (0.9961089494163424 0.9961089494163424 0.9961089494163424)
> 
> and
> 
> (color-name-to-rgb "white")
> ==>
> (1.0 1.0 1.0)

That's what should happen, yes.

> For the recipe of this bug report, the values are the same as without
> the patch.
> 
> I guess this is what you expected.

Yes, expected.  color-values were not affected by the change, it's
just that color.el is now consistent with what color-values returns.

> But is it ok that "#ffffff" is not equivalent to "white"?

Yes.  There's no other way, really, on systems where "white" has 3
16-bit components with all bits set, when color-values is called.

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

[Rasmus]

Hi,

Eli Zaretskii <eliz@gnu.org> writes:

> I think there's a bug in color.el: it assumes that the #RGB notation
> uses 24 bits, i.e. each component maxes out at 255.  But Emacs does
> its color calculations based on 16-bit components, which max out at
> 65535, which is why #ffffff does NOT produce (65535 65535 65535), the
> white color.  (We decided long ago to use 16-bit components because X
> APIs such as XParseColor on some systems, including yours, work with
> such components.)  IOW, #ffffff is parsed as #ff00ff00ff00, and that
> is not "white".
>
> So I think the patch below is what is needed to fix this problem.  Can
> you try it?  (There's one user of the functions the patch changes,
> shr-color.el, which will need to be adapted to the change, if we
> decide to install it.)

The test I used before now works for me:

    (set-frame-parameter (selected-frame) 'background-color
                         (color-darken-name "light yellow" 5))

Other noteworthy effects of the change were already addressed by Michael.

Thanks,
Rasmus

-- 
Hvor meget poesi tror De kommer ud af et glas isvand?

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

[Eli Zaretskii]

> From: Rasmus <rasmus@gmx.us>
> Date: Wed, 01 Mar 2017 10:55:22 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think there's a bug in color.el: it assumes that the #RGB notation
> > uses 24 bits, i.e. each component maxes out at 255.  But Emacs does
> > its color calculations based on 16-bit components, which max out at
> > 65535, which is why #ffffff does NOT produce (65535 65535 65535), the
> > white color.  (We decided long ago to use 16-bit components because X
> > APIs such as XParseColor on some systems, including yours, work with
> > such components.)  IOW, #ffffff is parsed as #ff00ff00ff00, and that
> > is not "white".
> >
> > So I think the patch below is what is needed to fix this problem.  Can
> > you try it?  (There's one user of the functions the patch changes,
> > shr-color.el, which will need to be adapted to the change, if we
> > decide to install it.)
> 
> The test I used before now works for me:
> 
>     (set-frame-parameter (selected-frame) 'background-color
>                          (color-darken-name "light yellow" 5))
> 
> Other noteworthy effects of the change were already addressed by Michael.

Thanks, I installed my change with minor variations, and I'm marking
this bug done.

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

[Eli Zaretskii]

> Date: Tue, 28 Feb 2017 15:54:46 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 25890@debbugs.gnu.org, Rasmus <rasmus@gmx.us>
> 
> > >  (defun color-rgb-to-hex  (red green blue)
> > >    "Return hexadecimal notation for the color RED GREEN BLUE.
> > >  RED, GREEN, and BLUE should be numbers between 0.0 and 1.0, inclusive."
> > > -  (format "#%02x%02x%02x"
> > > -          (* red 255) (* green 255) (* blue 255)))
> > > +  (format "#%04x%04x%04x"
> > > +          (* red 65535) (* green 65535) (* blue 65535)))
> 
> The function should accept an optional arg NB-DIGITS, which
> specifies the number of hex digits for each of R, G, B.  And
> yes, it should default to 4 digits: #RRRRGGGGBBBB.
> 
> (That's what the original function in hexrgb.el does, from
> which color.el was supposedly derived.)

The code in hexrgb.el produces strange results in this regard (e.g.,
it produces "#FFFFFFFFE0E0" instead of "#FFFFFFFFE000" for the color
mentioned by the OP).  I believe that's because it interprets the
conversion between 2 and 4 hex digits incorrectly: the 2 hex digits
are the _most_ significant bits of the 4-digit version, not the LSB.

But I did add such an optional argument to color-rgb-to-hex, with the
difference that its value can only be either 4 or 2, as I see no
reason for anyone to want a 12-bit per component color notations.

Thanks.

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

[Drew Adams]

> > > >  (defun color-rgb-to-hex  (red green blue)
> >
> > The function should accept an optional arg NB-DIGITS, which
> > specifies the number of hex digits for each of R, G, B.  And
> > yes, it should default to 4 digits: #RRRRGGGGBBBB.
> >
> > (That's what the original function in hexrgb.el does, from
> > which color.el was supposedly derived.)
> 
> The code in hexrgb.el produces strange results in this regard (e.g.,
> it produces "#FFFFFFFFE0E0" instead of "#FFFFFFFFE000" for the color
> mentioned by the OP).

Not clear what you are saying.  What color mentioned by the OP?
Do you mean "light yellow"?  What sexp using hexrgb.el did you try?  

If I do (hexrgb-color-name-to-hex "light yellow") I do get
"#FFFFFFFFE0E0".  That comes from `x-color-values' returning
(65535 65535 57568) and `hexrgb-int-to-hex' converting 57568
to "E0E0".  That's from (format "%04X" 57568).  Hex conversion
of decimal 57568 _should_ be E0E0, AFAIK.  Where is the bug?

Or are you saying that the bug is from `x-color-values'
(`color-values') and not from hexrgb.el?  Is 57568 the
wrong blue color value for "light yellow"?

> I believe that's because it interprets the
> conversion between 2 and 4 hex digits incorrectly: the 2 hex digits
> are the _most_ significant bits of the 4-digit version, not the LSB.

See above.  I'm missing what you are trying to say, I guess.
Are you saying that color value 57568 should not be expressed
in hex as E0E0?

> But I did add such an optional argument to color-rgb-to-hex,

Good.

> with the difference that its value can only be either 4 or 2,
> as I see no reason for anyone to want a 12-bit per component
> color notations.

(I see no reason for the function not to be general.  Sure,
for current applications of such a function to colors there
is no real need for such generality.  But why prevent it?)

Anyway, thanks for adding the optional arg.

I'm interested in your reply to my questions above,
especially in the case that might have located a bug in
hexrgb.el.  It's not clear to me, so far.  Thx.

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

[Eli Zaretskii]

> Date: Fri, 3 Mar 2017 07:49:33 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: michael_heerdegen@web.de, 25890@debbugs.gnu.org, rasmus@gmx.us
> 
> > The code in hexrgb.el produces strange results in this regard (e.g.,
> > it produces "#FFFFFFFFE0E0" instead of "#FFFFFFFFE000" for the color
> > mentioned by the OP).
> 
> Not clear what you are saying.  What color mentioned by the OP?
> Do you mean "light yellow"?  What sexp using hexrgb.el did you try?  
> 
> If I do (hexrgb-color-name-to-hex "light yellow") I do get
> "#FFFFFFFFE0E0".  That comes from `x-color-values' returning
> (65535 65535 57568) and `hexrgb-int-to-hex' converting 57568
> to "E0E0".  That's from (format "%04X" 57568).  Hex conversion
> of decimal 57568 _should_ be E0E0, AFAIK.  Where is the bug?

The bug is in hexrgb-int-to-hex: it incorrectly assumes that it should
produce the LSB part of the number, while it actually should produce
the MSB part.

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

[Drew Adams]

> > > The code in hexrgb.el produces strange results in this regard (e.g.,
> > > it produces "#FFFFFFFFE0E0" instead of "#FFFFFFFFE000" for the color
> > > mentioned by the OP).
> >
> > Not clear what you are saying.  What color mentioned by the OP?
> > Do you mean "light yellow"?  What sexp using hexrgb.el did you try?
> >
> > If I do (hexrgb-color-name-to-hex "light yellow") I do get
> > "#FFFFFFFFE0E0".  That comes from `x-color-values' returning
> > (65535 65535 57568) and `hexrgb-int-to-hex' converting 57568
> > to "E0E0".  That's from (format "%04X" 57568).  Hex conversion
> > of decimal 57568 _should_ be E0E0, AFAIK.  Where is the bug?
> 
> The bug is in hexrgb-int-to-hex: it incorrectly assumes that it should
> produce the LSB part of the number, while it actually should produce
> the MSB part.

You seem to be just repeating yourself, without answering my
questions.  Are you saying that hex conversion of decimal 57568
should not be E0E0?  If so, why?  Why should it be E000?

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

[Eli Zaretskii]

> Date: Fri, 3 Mar 2017 11:20:44 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: michael_heerdegen@web.de, 25890@debbugs.gnu.org, rasmus@gmx.us
> 
> Are you saying that hex conversion of decimal 57568 should not be
> E0E0?

No.

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

[Drew Adams]

> > Are you saying that hex conversion of decimal 57568 should not be
> > E0E0?
> 
> No.

Not very helpful.  It's not clear what you think is incorrect
in hexrgb.el, in that case.

You said:

> The bug is in hexrgb-int-to-hex: it incorrectly assumes that it should
> produce the LSB part of the number, while it actually should produce
> the MSB part.

`hexrgb-int-to-hex' just converts integer RGB to hex RGB.
And it converts integer 57568 to E0E0, which you now agree
is correct.

Perhaps you can elaborate a bit on what you think the bug is?

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

[Eli Zaretskii]

> Date: Fri, 3 Mar 2017 13:18:12 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: michael_heerdegen@web.de, 25890@debbugs.gnu.org, rasmus@gmx.us
> 
> You said:
> 
> > The bug is in hexrgb-int-to-hex: it incorrectly assumes that it should
> > produce the LSB part of the number, while it actually should produce
> > the MSB part.
> 
> `hexrgb-int-to-hex' just converts integer RGB to hex RGB.
> And it converts integer 57568 to E0E0, which you now agree
> is correct.
> 
> Perhaps you can elaborate a bit on what you think the bug is?

I already did, but you didn't want to hear, claiming that I repeat
myself.

Here it is again: 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.  It should instead produce the
most-significant digits.  IOW, when #FFFFFF is converted to 16-bit per
color component, it should yield #FF00FF00FF00, not #FFFFFFFFFFFF.

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

[Simen Heggestøyl]

On Fri, Mar 3, 2017 at 3:08 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> Thanks, I installed my change with minor variations, and I'm marking
> this bug done.

Thanks, Eli. The changes makes sense to me, but I've still got one
problem. I'm working with web colors, where color codes are specified
with either one or two digits per component (meaning that both "#fff"
and "#ffffff" specify the brightest possible value, named
"white"). But:

(apply #'color-rgb-to-hex `(,@(color-name-to-rgb "#ffffff") 2))
     => "#fefefe"

(apply #'color-rgb-to-hex `(,@(color-name-to-rgb "#fff") 2))
     => "#efefef"

Where I would like both to give back "#ffffff". Does this mean that I
have to ensure that input to `color-name-to-rgb' uses 4 digits per
component? Would it make sense for it to get a new optional parameter
`DIGITS-PER-COMPONENT', like `color-rgb-to-hex' did?

-- Simen

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

[Eli Zaretskii]

> Date: Sat, 04 Mar 2017 15:24:00 +0100
> From: Simen Heggestøyl <simenheg@gmail.com>
> Cc: 25890-done@debbugs.gnu.org
> 
> Thanks, Eli. The changes makes sense to me, but I've still got one
> problem. I'm working with web colors, where color codes are specified
> with either one or two digits per component (meaning that both "#fff"
> and "#ffffff" specify the brightest possible value, named
> "white"). But:
> 
> (apply #'color-rgb-to-hex `(,@(color-name-to-rgb "#ffffff") 2))
>      => "#fefefe"
> 
> (apply #'color-rgb-to-hex `(,@(color-name-to-rgb "#fff") 2))
>      => "#efefef"
> 
> Where I would like both to give back "#ffffff". Does this mean that I
> have to ensure that input to `color-name-to-rgb' uses 4 digits per
> component?

Yes, IMO.  Emacs does all its calculations with color components
assuming 16 bits per component.  Applications that need to use fewer
digits and have the missing digits as something other than zero, need
to do that in application code.

> Would it make sense for it to get a new optional parameter
> `DIGITS-PER-COMPONENT', like `color-rgb-to-hex' did?

Not IMO, because only the application knows what it means by #ffffff,
color.el has no way of knowing that.  So it would be best to leave
this for the application to do, by converting the #RGB spec to the
canonical 16-bits-per-component form.

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

[Drew Adams]

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

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> (apply #'color-rgb-to-hex `(,@(color-name-to-rgb "#ffffff") 2))
>>      => "#fefefe"
>> 
>> (apply #'color-rgb-to-hex `(,@(color-name-to-rgb "#fff") 2))
>>      => "#efefef"
>> 
>> Where I would like both to give back "#ffffff". Does this mean that I
>> have to ensure that input to `color-name-to-rgb' uses 4 digits per
>> component?
>
> Yes, IMO.  Emacs does all its calculations with color components
> assuming 16 bits per component.  Applications that need to use fewer
> digits and have the missing digits as something other than zero, need
> to do that in application code.

I haven't followed this discussion closely, but you've changed the way
color-rgb-to-rgb works in an incompatible way?  I don't think that makes
much sense -- it's a function we must assume is used by third party code
and that's supposed to return certain values on certain inputs.

If you want to have a function that does something else, I think it
would make more sense to introduce new functions that does this
"something new" (i.e., 16 bit component parsing instead of HTML-like
color parsing, which is what those functions are supposed to do), and
revert the old functions how they used to work.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> Date: Sat, 4 Mar 2017 07:38:51 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: michael_heerdegen@web.de, 25890@debbugs.gnu.org, rasmus@gmx.us
> 
> > It should instead produce the most-significant digits.
> 
> Why?

Because that's how colors are interpreted on X, which is where Emacs
takes its ideas of how to process these specs.  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.)

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

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.

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Simen Heggestøyl <simenheg@gmail.com>,
>   25890@debbugs.gnu.org,  rasmus@gmx.us
> Date: Sat, 04 Mar 2017 16:44:28 +0100
> 
> I haven't followed this discussion closely, but you've changed the way
> color-rgb-to-rgb works in an incompatible way?

There's no color-rgb-to-rgb.  There's color-rgb-to-hex and
color-name-to-rgb.  And I don't think the changes are incompatible.
Please show examples if you think otherwise.

> If you want to have a function that does something else, I think it
> would make more sense to introduce new functions that does this
> "something new" (i.e., 16 bit component parsing instead of HTML-like
> color parsing, which is what those functions are supposed to do), and
> revert the old functions how they used to work.

The changes make the above 2 functions compatible with all the other
color calculations in Emacs.  IMO it makes no sense to have color.el
make assumptions about RGB components that are different from
everything else in Emacs, as doing so will only produce subtle bugs
such as the one which started this bug report.

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.

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

[mail]

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

Hello,

I'd like to ask a question regarding to the commit 7b00e956.
I quickly scanned the discussion here, but couldn't find any good reason for changing the behavior of color-rgb-to-hex function without keeping backward compatibility;
why the default value for digits-per-component is 4, not 2?
This change actually had impact on several packages including mode-icons, and IMO keeping the original behavior is a better option.

Thanks,
kissge

[-- Attachment #2: Type: text/html, Size: 731 bytes --]

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

[Eli Zaretskii]

> From: "mail@yo.eki.do" <mail@yo.eki.do>
> Date: Fri, 10 Mar 2017 05:23:35 +0000
> 
> I'd like to ask a question regarding to the commit 7b00e956.
> I quickly scanned the discussion here, but couldn't find any good reason for changing the behavior of
> color-rgb-to-hex function without keeping backward compatibility;
> why the default value for digits-per-component is 4, not 2?

The default was changed to 4 to match how Emacs does color
calculations internally.  Using 2 will produce subtle bugs, like that
one which prompted that change.

> This change actually had impact on several packages including mode-icons, and IMO keeping the original
> behavior is a better option.

I'm sorry to hear that, but you could still use the optional argument
to get back the original behavior, right?

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

[mail]

2017-03-10 16:28 GMT+09:00 Eli Zaretskii <eliz@gnu.org>:
>
> > From: "mail@yo.eki.do" <mail@yo.eki.do>
> > Date: Fri, 10 Mar 2017 05:23:35 +0000
> >
> > I'd like to ask a question regarding to the commit 7b00e956.
> > I quickly scanned the discussion here, but couldn't find any good reason for changing the behavior of
> > color-rgb-to-hex function without keeping backward compatibility;
> > why the default value for digits-per-component is 4, not 2?
>
> The default was changed to 4 to match how Emacs does color
> calculations internally.  Using 2 will produce subtle bugs, like that
> one which prompted that change.

Thanks for clear explanation.
So that basically means this destructive change was inevitable.
I guess you are right.

> > This change actually had impact on several packages including mode-icons, and IMO keeping the original
> > behavior is a better option.
>
> I'm sorry to hear that, but you could still use the optional argument
> to get back the original behavior, right?

Hopefully. Actually I'm not qute certain how many packages will be affected.

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

[mail]

2017-03-10 17:13 GMT+09:00 mail@yo.eki.do <mail@yo.eki.do>:
>> > This change actually had impact on several packages including mode-icons, and IMO keeping the original
>> > behavior is a better option.
>>
>> I'm sorry to hear that, but you could still use the optional argument
>> to get back the original behavior, right?
>
> Hopefully. Actually I'm not qute certain how many packages will be affected.

No, let me take back my words.
This change will have too large impacts since the number of parameters
will change.
Indeed developers can use the optional argument, but that trick won't
work in the previous version of Emacs and will lead to
wrong-number-of-arguments errors,
so they will need burdensome workarounds e.g. version check.
I'd have to say that the default argument should stick to 2, the original.

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

[Eli Zaretskii]

> From: "mail@yo.eki.do" <mail@yo.eki.do>
> Date: Fri, 10 Mar 2017 08:13:15 +0000
> 
> > The default was changed to 4 to match how Emacs does color
> > calculations internally.  Using 2 will produce subtle bugs, like that
> > one which prompted that change.
> 
> Thanks for clear explanation.
> So that basically means this destructive change was inevitable.
> I guess you are right.

To my defense, they didn't look so destructive when I made them.  This
function has only one caller in the rest of the Emacs sources.

> > > This change actually had impact on several packages including mode-icons, and IMO keeping the original
> > > behavior is a better option.
> >
> > I'm sorry to hear that, but you could still use the optional argument
> > to get back the original behavior, right?
> 
> Hopefully. Actually I'm not qute certain how many packages will be affected.

Neither am I.

I'm open to alternative ideas for how to solve the original bug in a
less intrusive way.  I just don't think defaulting to 2 would be such
an alternative, because the underlying issues are very subtle, and if
we continue using 2 as the default, users of that function will never
discover that they need to use 4.  But maybe there are other ways that
leave everyone more happy.

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

[Eli Zaretskii]

> From: "mail@yo.eki.do" <mail@yo.eki.do>
> Date: Fri, 10 Mar 2017 08:33:59 +0000
> 
> This change will have too large impacts since the number of parameters
> will change.
> Indeed developers can use the optional argument, but that trick won't
> work in the previous version of Emacs and will lead to
> wrong-number-of-arguments errors,
> so they will need burdensome workarounds e.g. version check.

Packages that need to support older versions of Emacs will have to
provide a wrapper function that indeed looks at emacs-version.  That's
nothing new.

> I'd have to say that the default argument should stick to 2, the original.

That would leave the original problem in place, so I don't think it's
acceptable.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm open to alternative ideas for how to solve the original bug in a
> less intrusive way.  I just don't think defaulting to 2 would be such
> an alternative, because the underlying issues are very subtle, and if
> we continue using 2 as the default, users of that function will never
> discover that they need to use 4.  But maybe there are other ways that
> leave everyone more happy.

The normal way to introduce incompatible changes like this is to
introduce a new function and mark the old function as obsolete, isn't
it?  (Then remove the old function in about ten years time.  :-))

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: "mail\@yo.eki.do" <mail@yo.eki.do>,  25890@debbugs.gnu.org
> Date: Fri, 10 Mar 2017 12:07:18 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I'm open to alternative ideas for how to solve the original bug in a
> > less intrusive way.  I just don't think defaulting to 2 would be such
> > an alternative, because the underlying issues are very subtle, and if
> > we continue using 2 as the default, users of that function will never
> > discover that they need to use 4.  But maybe there are other ways that
> > leave everyone more happy.
> 
> The normal way to introduce incompatible changes like this is to
> introduce a new function and mark the old function as obsolete, isn't
> it?  (Then remove the old function in about ten years time.  :-))

I asked about that in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25525#68,
but no one answered.  The disadvantage would be that those packages
need to change their code anyway, now or in "ten years time".  If
that's deemed a better way, I can do it.

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

[mail]

2017-03-10 18:28 GMT+09:00 Eli Zaretskii <eliz@gnu.org>:
> Packages that need to support older versions of Emacs will have to
> provide a wrapper function that indeed looks at emacs-version.  That's
> nothing new.

Yes, you are right.
The point is, if it is possible, preserving the original behavior
would produce less confusion for developers.

2017-03-10 18:28 GMT+09:00 Eli Zaretskii <eliz@gnu.org>:
>> From: "mail@yo.eki.do" <mail@yo.eki.do>
>> Date: Fri, 10 Mar 2017 08:33:59 +0000
>>
>> This change will have too large impacts since the number of parameters
>> will change.
>> Indeed developers can use the optional argument, but that trick won't
>> work in the previous version of Emacs and will lead to
>> wrong-number-of-arguments errors,
>> so they will need burdensome workarounds e.g. version check.
>
> Packages that need to support older versions of Emacs will have to
> provide a wrapper function that indeed looks at emacs-version.  That's
> nothing new.
>
>> I'd have to say that the default argument should stick to 2, the original.
>
> That would leave the original problem in place, so I don't think it's
> acceptable.

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

[mail]

2017-03-10 22:32 GMT+09:00 Eli Zaretskii <eliz@gnu.org>:
> I asked about that in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25525#68,
> but no one answered.  The disadvantage would be that those packages
> need to change their code anyway, now or in "ten years time".  If
> that's deemed a better way, I can do it.

Now I understand the situation.
So far, "to introduce a new function and mark the old function as
obsolete" sounds the best idea.

bug#25890: Default value of digits-per-component?

[Clément Pit-Claudel]

Hi all,

> When I worked on the change, it seemed harmless: the function has only
> one caller outside of color.el, and I changed that single caller to
> use the optional argument.

This is a public function, with many callers outside of Emacs, it seems (https://github.com/search?l=Emacs+Lisp&q=color-rgb-to-hex&type=Code&utf8=%E2%9C%93); it will certainly break some of these uses (it did break my uses of it :/) I tend to follow the ChangeLogs and emacs-devel discussions, but I didn't see it mentioned there; maybe it would be good to?

> If the change I made is nevertheless deemed too drastic, then what are
> our alternatives?  The only one I could think of is to define a new
> function and deprecate color-name-to-rgb in favor of that new
> function, which will then display warnings when code using it is
> compiled, and eventually cause them to make changes in their code
> anyway.  Is that better?  Or are there any better ideas?

It sounds much better to me: the current solution breaks all code silently, while a new function doesn't break any code and me authors time to adjust.  Additionally, with a new function, it's easy to write code that's compatible with all versions of Emacs (I just check whether the new function is fboundp).  With the current change, I have to inspect the function's signature to determine how to call it (is there a simpler way?).

An alternative is to advertise the argument as required, default to '2', and issue a warning when that argument isn't explicitly specified — a bit like what was done with looking-back.

Thanks!
Clément.

bug#25890: Default value of digits-per-component?

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Wed, 29 Mar 2017 16:01:09 -0400
> 
> > If the change I made is nevertheless deemed too drastic, then what are
> > our alternatives?  The only one I could think of is to define a new
> > function and deprecate color-name-to-rgb in favor of that new
> > function, which will then display warnings when code using it is
> > compiled, and eventually cause them to make changes in their code
> > anyway.  Is that better?  Or are there any better ideas?
> 
> It sounds much better to me: the current solution breaks all code silently

I'm not sure I understand how come all users of that function are
suddenly broken.  A different result doesn't yet mean breakage, unless
the caller actually expected the precise format the old version was
producing, and relied on that.  Is that indeed so in the callers you
saw?

bug#25890: Default value of digits-per-component?

[Clément Pit-Claudel]

On 2017-03-29 22:36, Eli Zaretskii wrote:
>> Cc: Eli Zaretskii <eliz@gnu.org>
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Wed, 29 Mar 2017 16:01:09 -0400
>>
>>> If the change I made is nevertheless deemed too drastic, then what are
>>> our alternatives?  The only one I could think of is to define a new
>>> function and deprecate color-name-to-rgb in favor of that new
>>> function, which will then display warnings when code using it is
>>> compiled, and eventually cause them to make changes in their code
>>> anyway.  Is that better?  Or are there any better ideas?
>>
>> It sounds much better to me: the current solution breaks all code silently
> 
> I'm not sure I understand how come all users of that function are
> suddenly broken.  A different result doesn't yet mean breakage, unless
> the caller actually expected the precise format the old version was
> producing, and relied on that.  Is that indeed so in the callers you
> saw?

For me, yes, definitely: I was producing HTML webpages with inline CSS and LaTeX documents.  Both of these got very confused when they started receiving a longer hex codes :)
I don't know about the uses on GitHub. 

Clément.