Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream

Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> branch: master
> commit 11f10dc0d0b4b1d6af828102421eac9f79e0fcba
> Author: Stefan Kangas <stefankangas@gmail.com>
> Commit: Stefan Kangas <stefankangas@gmail.com>
>
>     Update etc/rgb.txt from X.Org upstream
>     
>     The upstream version contains the following changes:
>     
>       2023-07-10  rgb: Make color entries uniform
>       2014-07-06  Add aliases for colors that differ between X11 and CSS
>       2014-07-06  Add missing colors from CSS Color Module Level 4
>       2008-06-04  Nuke CVS version tags
>       2003-11-14  R6.6 is the Xorg base-line
>     
>     * etc/rgb.txt: Sync with the version in X.Org upstream
>     https://cgit.freedesktop.org/xorg/app/rgb/tree/rgb.txt
>     commit 0d2caecebf0e2a10994c22960921f366dd98d19a.  (Bug#66538)

Incidentally, this doesn't resolve bug#66538 because colors are supplied
by individual X servers or the toolkit under either X or PGTK.  It only
introduces new and unportable color names under Android, NS, MS-Windows,
and Haiku.

Striving for perfect consistency in color names between systems is a
pointless exercise, for X servers are given a blank check to modify
local colors as they see fit, generally in a crude attempt at color
calibration for the system's monitor.

Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 15 Oct 2023 09:10:24 +0800
> 
> Striving for perfect consistency in color names between systems is a
> pointless exercise, for X servers are given a blank check to modify
> local colors as they see fit, generally in a crude attempt at color
> calibration for the system's monitor.

I agree.  I think we should revert that commit, and I see no bug in
the fact that Emacs shows slightly different colors in different GUI
environments.

Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

>>     * etc/rgb.txt: Sync with the version in X.Org upstream
>>     https://cgit.freedesktop.org/xorg/app/rgb/tree/rgb.txt
>>     commit 0d2caecebf0e2a10994c22960921f366dd98d19a.  (Bug#66538)
>
> Incidentally, this doesn't resolve bug#66538 because ...

The point was not to fix Bug#66538, sorry for not being more clear.

I sometimes add references to bug reports so readers can know which
discussion provoked it.  I find such references helpful.  If that
practice is discouraged, I would certainly like to hear about it.

Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> The point was not to fix Bug#66538, sorry for not being more clear.

At any rate, you've introduced several colors (those named ``web'' and
``x11'') that are only available under a subset of the systems we
support.  So let's return to the old version of rgb.txt, lest packages
begin to use them and suffer the portability ramifications thereof.

For reference, on the computer I type this from:

  (x-color-values "web Green")

returns nil.  The X server is:

Window system distributor: 'Sun Microsystems, Inc.', version 11.0.6620

Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> Striving for perfect consistency in color names between systems is a
>> pointless exercise, for X servers are given a blank check to modify
>> local colors as they see fit, generally in a crude attempt at color
>> calibration for the system's monitor.

I'm not quite following.  Are you referencing aesthetic differences or
older X server behaviors?  Could you clarify the reason behind
maintaining this difference with X.Org?

> I agree.  I think we should revert that commit,

While I'm not entirely clear on the details, I won't oppose that.
I'm less inclined to dive deep into discussions about older X server
intricacies.

Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> I'm not quite following.  Are you referencing aesthetic differences or
> older X server behaviors?  Could you clarify the reason behind
> maintaining this difference with X.Org?

Because circa 2020 X.Org is not the only X server we support, and it is
thus our duty to deter Lisp code from using color names exclusive to it.

One manner in which that duty is fulfilled is by omitting such names
from ports that don't consult the display server's color database,
namely those which load colors from rgb.txt.

Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream

[Mattias Engdegård]

For those who wondered what the exact changes were, a summary:

New aliases for existing colours:

190 190 190   x11 gray, X11Gray, x11 grey, X11Grey  (= grey)
  0 255   0   x11 green, X11Green                   (= green)
176  48  96   x11 maroon, X11Maroon                 (= maroon)
160  32 240   x11 purple, X11Purple                 (= purple)

  0 255 255   aqua                                  (= cyan)
  0 255   0   lime                                  (= green)
255   0 255   fuchsia                               (= magenta)

New colours:

128 128 128   web gray, WebGray, web grey, WebGrey
  0 128   0   web green, WebGreen
128   0   0   web maroon, WebMaroon
128   0 128   web purple, WebPurple

220  20  60   crimson
 75   0 130   indigo
128 128   0   olive
102  51 153   rebecca purple, RebeccaPurple
192 192 192   silver
  0 128 128   teal

And nothing else.

Seems fairly harmless to me, but also not very useful.

Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> At any rate, you've introduced several colors (those named ``web'' and
> ``x11'') that are only available under a subset of the systems we
> support.  So let's return to the old version of rgb.txt, lest packages
> begin to use them and suffer the portability ramifications thereof.

While using portable colors is a concern, it seems orthogonal.  X.Org
ships with these colors, and as things stand, nothing is stopping them
from being used.  We could perhaps recommend against using them, and not
much else.

> For reference, on the computer I type this from:
>
>   (x-color-values "web Green")
>
> returns nil.  The X server is:
>
> Window system distributor: 'Sun Microsystems, Inc.', version 11.0.6620

While the potential issues for Solaris users are understood, I believe
we should weigh that against other platforms.

Reverting will mean that these colors won't work for users on some of
our most commonly used platforms.  That's all.  Is it good practice to
leave such things broken on some platforms, in the hope that it will be
enough to provoke Emacs Lisp developers to fix it on some others?

Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> While using portable colors is a concern, it seems orthogonal.  X.Org
> ships with these colors, and as things stand, nothing is stopping them
> from being used.  We could perhaps recommend against using them, and
> not much else.

We shouldn't distribute non-standard color files in the first place:
users should have no occasion to use them, so the less places they are
mentioned or available in, the better.

> Reverting will mean that these colors won't work for users on some of
> our most commonly used platforms.  That's all.  Is it good practice to
> leave such things broken on some platforms, in the hope that it will
> be enough to provoke Emacs Lisp developers to fix it on some others?

Yes, since "web" colors are easily specified through their RGB values,
and "x11" colors are identical to their unprefixed progenitors.

Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> While using portable colors is a concern, it seems orthogonal.  X.Org
>> ships with these colors, and as things stand, nothing is stopping them
>> from being used.  We could perhaps recommend against using them, and
>> not much else.
>
> We shouldn't distribute non-standard color files in the first place:

I don't know which standard this is referring to.  XFree86R6?

> users should have no occasion to use them, so the less places they are
> mentioned or available in, the better.

AFAIK, nothing is stopping their use on X.Org so, whatever you and I
might think of it, it is clear that users can and will use them.

>> Reverting will mean that these colors won't work for users on some of
>> our most commonly used platforms.  That's all.  Is it good practice to
>> leave such things broken on some platforms, in the hope that it will
>> be enough to provoke Emacs Lisp developers to fix it on some others?
>
> Yes, since "web" colors are easily specified through their RGB values,
> and "x11" colors are identical to their unprefixed progenitors.

I didn't ask if alternatives existed, but if we should leave this
non-working on some of our most commonly used systems for the benefit of
Solaris users (the only example given so far).  I see no catastrophe
either way, to be quite honest.

Anyways, you seem to care more strongly than I do, so I'll leave the
decision to you.  I remain unconvinced, but we can agree to disagree.
For next time, please consider that it might be more collaborative to
wait with reverting, to make sure that all viewpoints are fully
considered.

Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> I don't know which standard this is referring to.  XFree86R6?

X11R6, from the X Consortium, since that is the earliest release of X11
we support.

> AFAIK, nothing is stopping their use on X.Org so, whatever you and I
> might think of it, it is clear that users can and will use them.

Users won't use them if we don't purvey them through rgb.txt.  They are
also absent from list-colors-display.

> I didn't ask if alternatives existed, but if we should leave this
> non-working on some of our most commonly used systems for the benefit of
> Solaris users (the only example given so far).  I see no catastrophe
> either way, to be quite honest.

Since Emacs built on any machine is capable of connecting to _any_ other
X11R6 server, advertising such colors will affect Emacs on any system,
not merely systems distributed with X.Org servers older than 2014.  And
I'd contend that such "cured", if you will, X servers constitute, if not
the majority, then a substantial share of the multitude of X servers
presently in use.

Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Tue, 17 Oct 2023 09:24:20 +0000
> Cc: emacs-devel@gnu.org
> 
> I didn't ask if alternatives existed, but if we should leave this
> non-working on some of our most commonly used systems for the benefit of
> Solaris users (the only example given so far).  I see no catastrophe
> either way, to be quite honest.

Why "non-working"?  AFAIU, Emacs on X uses the colors known to the X
server, and doesn't consult that file.  That file is only consulted on
non-X platforms, such as MS-Windows.  So using it would mean that
Emacs on MS-Windows will support colors that Emacs on X might not
support (if the X server doesn't).  Do we really want that?