* Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream [not found] ` <20231014192414.36BEBC09BCA@vcs2.savannah.gnu.org> @ 2023-10-15 1:10 ` Po Lu 2023-10-15 5:50 ` Eli Zaretskii 2023-10-15 7:09 ` Stefan Kangas 0 siblings, 2 replies; 12+ messages in thread From: Po Lu @ 2023-10-15 1:10 UTC (permalink / raw) To: emacs-devel; +Cc: Stefan Kangas 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream 2023-10-15 1:10 ` master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream Po Lu @ 2023-10-15 5:50 ` Eli Zaretskii 2023-10-15 7:43 ` Stefan Kangas 2023-10-15 7:09 ` Stefan Kangas 1 sibling, 1 reply; 12+ messages in thread From: Eli Zaretskii @ 2023-10-15 5:50 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel, stefankangas > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream 2023-10-15 5:50 ` Eli Zaretskii @ 2023-10-15 7:43 ` Stefan Kangas 2023-10-15 7:59 ` Po Lu 2023-10-15 9:38 ` Mattias Engdegård 0 siblings, 2 replies; 12+ messages in thread From: Stefan Kangas @ 2023-10-15 7:43 UTC (permalink / raw) To: Eli Zaretskii, Po Lu; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream 2023-10-15 7:43 ` Stefan Kangas @ 2023-10-15 7:59 ` Po Lu 2023-10-15 9:38 ` Mattias Engdegård 1 sibling, 0 replies; 12+ messages in thread From: Po Lu @ 2023-10-15 7:59 UTC (permalink / raw) To: Stefan Kangas; +Cc: Eli Zaretskii, emacs-devel 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream 2023-10-15 7:43 ` Stefan Kangas 2023-10-15 7:59 ` Po Lu @ 2023-10-15 9:38 ` Mattias Engdegård 1 sibling, 0 replies; 12+ messages in thread From: Mattias Engdegård @ 2023-10-15 9:38 UTC (permalink / raw) To: Stefan Kangas; +Cc: Eli Zaretskii, Po Lu, emacs-devel 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream 2023-10-15 1:10 ` master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream Po Lu 2023-10-15 5:50 ` Eli Zaretskii @ 2023-10-15 7:09 ` Stefan Kangas 2023-10-15 7:41 ` Po Lu 1 sibling, 1 reply; 12+ messages in thread From: Stefan Kangas @ 2023-10-15 7:09 UTC (permalink / raw) To: Po Lu, emacs-devel 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream 2023-10-15 7:09 ` Stefan Kangas @ 2023-10-15 7:41 ` Po Lu 2023-10-16 14:33 ` Stefan Kangas 0 siblings, 1 reply; 12+ messages in thread From: Po Lu @ 2023-10-15 7:41 UTC (permalink / raw) To: Stefan Kangas; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream 2023-10-15 7:41 ` Po Lu @ 2023-10-16 14:33 ` Stefan Kangas 2023-10-16 23:49 ` Po Lu 0 siblings, 1 reply; 12+ messages in thread From: Stefan Kangas @ 2023-10-16 14:33 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream 2023-10-16 14:33 ` Stefan Kangas @ 2023-10-16 23:49 ` Po Lu 2023-10-17 9:24 ` Stefan Kangas 0 siblings, 1 reply; 12+ messages in thread From: Po Lu @ 2023-10-16 23:49 UTC (permalink / raw) To: Stefan Kangas; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream 2023-10-16 23:49 ` Po Lu @ 2023-10-17 9:24 ` Stefan Kangas 2023-10-17 10:45 ` Po Lu 2023-10-17 11:10 ` Eli Zaretskii 0 siblings, 2 replies; 12+ messages in thread From: Stefan Kangas @ 2023-10-17 9:24 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream 2023-10-17 9:24 ` Stefan Kangas @ 2023-10-17 10:45 ` Po Lu 2023-10-17 11:10 ` Eli Zaretskii 1 sibling, 0 replies; 12+ messages in thread From: Po Lu @ 2023-10-17 10:45 UTC (permalink / raw) To: Stefan Kangas; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream 2023-10-17 9:24 ` Stefan Kangas 2023-10-17 10:45 ` Po Lu @ 2023-10-17 11:10 ` Eli Zaretskii 1 sibling, 0 replies; 12+ messages in thread From: Eli Zaretskii @ 2023-10-17 11:10 UTC (permalink / raw) To: Stefan Kangas; +Cc: luangruo, emacs-devel > 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2023-10-17 11:10 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <169731145392.6616.366366221046340825@vcs2.savannah.gnu.org> [not found] ` <20231014192414.36BEBC09BCA@vcs2.savannah.gnu.org> 2023-10-15 1:10 ` master 11f10dc0d0b: Update etc/rgb.txt from X.Org upstream Po Lu 2023-10-15 5:50 ` Eli Zaretskii 2023-10-15 7:43 ` Stefan Kangas 2023-10-15 7:59 ` Po Lu 2023-10-15 9:38 ` Mattias Engdegård 2023-10-15 7:09 ` Stefan Kangas 2023-10-15 7:41 ` Po Lu 2023-10-16 14:33 ` Stefan Kangas 2023-10-16 23:49 ` Po Lu 2023-10-17 9:24 ` Stefan Kangas 2023-10-17 10:45 ` Po Lu 2023-10-17 11:10 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).