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]

> 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

[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

[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

[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]

> 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

[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: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 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

[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

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