GNU bug report logs -
#36304
27.0.50; request: switch to the superior HTML #RGB convention for colors
Previous Next
Reported by: Pip Cet <pipcet <at> gmail.com>
Date: Thu, 20 Jun 2019 11:24:01 UTC
Severity: wishlist
Found in version 27.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36304 in the body.
You can then email your comments to 36304 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36304
; Package
emacs
.
(Thu, 20 Jun 2019 11:24:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Pip Cet <pipcet <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 20 Jun 2019 11:24:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
This is a request for an incompatible change, which I think will
improve some matters significantly:
The Web convention, used by HTML and SVG, is that #fff is parsed as
#ffffff, and represents "white". The X convention, discouraged for
years, is to accept #fff as shorthand for #f0f0f0, and #ffffff as
shorthand for #ff00ff00ff00, with no way of specifying the whitest
color as six (or three) hex digits.
We're still using the X convention. It's time to switch. The HTML
convention is what virtually everyone would expect these days, it
allows specifying "white" concisely, and it's what we use in some
contexts, such as when rendering SVGs.
Not fixing this would result in somewhat hard-to-track-down color bugs
all over the place, particularly when combining images and text or
using non-X window systems or non-8-bit color depths (again, "#ffffff"
isn't the same as "white" on those!)
There's no reason, as far as I can see, to burden everyone with a
deficiency of one specific graphics backend, in perpetuity,
particularly since the colors will stay similar but not quite the
same.
This issue was discussed years ago as bug #8402, so feel free to mark
this as a duplicate if it helps.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36304
; Package
emacs
.
(Fri, 21 Jun 2019 01:55:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 36304 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> We're still using the X convention. It's time to switch. The HTML
> convention is what virtually everyone would expect these days, it
> allows specifying "white" concisely, and it's what we use in some
> contexts, such as when rendering SVGs.
It seems plausible to me, speaking as a non-expert.
--
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36304
; Package
emacs
.
(Sat, 22 Jun 2019 11:25:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 36304 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Jun 21, 2019 at 1:54 AM Richard Stallman <rms <at> gnu.org> wrote:
> > We're still using the X convention. It's time to switch. The HTML
> > convention is what virtually everyone would expect these days, it
> > allows specifying "white" concisely, and it's what we use in some
> > contexts, such as when rendering SVGs.
>
> It seems plausible to me, speaking as a non-expert.
Here's a patch. I've read the documentation and it appears already to
have been updated by someone so it no longer links to the X
documentation.
* src/xterm.c (x_parse_color): Translate #RGB notation to rgb:R/G/B
notation, which X handles slightly differently.
---
src/xterm.c | 32 ++++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/src/xterm.c b/src/xterm.c
index 1acff2af0d..614774f6bc 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -2381,6 +2381,8 @@ x_query_frame_background_color (struct frame *f,
XColor *bgcolor)
x_query_colors (f, bgcolor, 1);
}
+#define HEX_COLOR_NAME_LENGTH 32
+
/* On frame F, translate the color name to RGB values. Use cached
information, if possible.
@@ -2398,9 +2400,35 @@ x_query_frame_background_color (struct frame
*f, XColor *bgcolor)
if (color_name[0] == '#')
{
- /* The hex form is parsed directly by XParseColor without
+ /* Don't pass #RGB strings directly to XParseColor, because that
+ follows the old convention of zero-extending each channel
+ value: #f00 means #f00000. We want the new convention of
+ scaling channel values, so #f00 means #ff0000.
+
+ So we translate #f00 to rgb:f/0/0, which X handles
+ differently. */
+ char rgb_color_name[HEX_COLOR_NAME_LENGTH];
+ int len = strlen (color_name);
+ int digits_per_channel;
+ if (len == 4)
+ digits_per_channel = 1;
+ else if (len == 7)
+ digits_per_channel = 2;
+ else if (len == 10)
+ digits_per_channel = 3;
+ else if (len == 13)
+ digits_per_channel = 4;
+ else
+ return 0;
+
+ snprintf (rgb_color_name, sizeof rgb_color_name, "rgb:%.*s/%.*s/%.*s",
+ digits_per_channel, color_name + 1,
+ digits_per_channel, color_name + digits_per_channel + 1,
+ digits_per_channel, color_name + 2 * digits_per_channel + 1);
+
+ /* The rgb form is parsed directly by XParseColor without
talking to the X server. No need for caching. */
- return XParseColor (dpy, cmap, color_name, color);
+ return XParseColor (dpy, cmap, rgb_color_name, color);
}
for (cache_entry = FRAME_DISPLAY_INFO (f)->color_names; cache_entry;
--
2.20.1
[0001-Change-color-convention-so-f00-means-the-same-as-ff0.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36304
; Package
emacs
.
(Sat, 22 Jun 2019 11:41:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 36304 <at> debbugs.gnu.org (full text, mbox):
> From: Pip Cet <pipcet <at> gmail.com>
> Date: Sat, 22 Jun 2019 11:23:35 +0000
> Cc: 36304 <at> debbugs.gnu.org
>
> Here's a patch. I've read the documentation and it appears already to
> have been updated by someone so it no longer links to the X
> documentation.
>
> * src/xterm.c (x_parse_color): Translate #RGB notation to rgb:R/G/B
> notation, which X handles slightly differently.
Can this change be limited to xterm.c alone? I think we assume this
color handling also in xfaces.c and in lisp/term/tty-colors.el (and
perhaps elsewhere, where TTY colors are used/defined). There's also
lisp/color.el.
Am I missing something?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36304
; Package
emacs
.
(Sat, 22 Jun 2019 12:15:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 36304 <at> debbugs.gnu.org (full text, mbox):
On Sat, Jun 22, 2019 at 11:40 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Pip Cet <pipcet <at> gmail.com>
> > Date: Sat, 22 Jun 2019 11:23:35 +0000
> > Cc: 36304 <at> debbugs.gnu.org
> >
> > Here's a patch. I've read the documentation and it appears already to
> > have been updated by someone so it no longer links to the X
> > documentation.
> >
> > * src/xterm.c (x_parse_color): Translate #RGB notation to rgb:R/G/B
> > notation, which X handles slightly differently.
>
> Can this change be limited to xterm.c alone?
It'd leave us inconsistently still using the X standard in some
places, but at first glance they appear to be documented to use the X
standard, so maybe that's not wrong.
> I think we assume this color handling also in xfaces.c
Only via tty-color-standard-values, as far as I can see.
> and in lisp/term/tty-colors.el (and perhaps elsewhere, where TTY colors are used/defined).
tty-color-standard-values is documented to use the X convention, and
it does. tty-color-desc is documented to return approximate results,
and it does; and it's only used for text terminals, right?
> There's also lisp/color.el.
Anything in particular? As far as I can tell, the functions work
properly using the new convention with this patch, although I am sure
there are places that fail to deal with the 65280-as-maximum
convention that nsfns.m uses.
> Am I missing something?
I don't think so, but I don't see anything, so far, that needs
changing. I'm almost certain that some more places will need changing,
but how do we find them?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36304
; Package
emacs
.
(Sat, 22 Jun 2019 12:37:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 36304 <at> debbugs.gnu.org (full text, mbox):
> From: Pip Cet <pipcet <at> gmail.com>
> Date: Sat, 22 Jun 2019 12:13:20 +0000
> Cc: rms <at> gnu.org, 36304 <at> debbugs.gnu.org
>
> On Sat, Jun 22, 2019 at 11:40 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > From: Pip Cet <pipcet <at> gmail.com>
> > > Date: Sat, 22 Jun 2019 11:23:35 +0000
> > > Cc: 36304 <at> debbugs.gnu.org
> > >
> > > Here's a patch. I've read the documentation and it appears already to
> > > have been updated by someone so it no longer links to the X
> > > documentation.
> > >
> > > * src/xterm.c (x_parse_color): Translate #RGB notation to rgb:R/G/B
> > > notation, which X handles slightly differently.
> >
> > Can this change be limited to xterm.c alone?
>
> It'd leave us inconsistently still using the X standard in some
> places, but at first glance they appear to be documented to use the X
> standard, so maybe that's not wrong.
I'm not sure I understand what you mean by "the X standard". Is that
the old or the new convention of how to interpret a given #RGB value?
> > I think we assume this color handling also in xfaces.c
>
> Only via tty-color-standard-values, as far as I can see.
>
> > and in lisp/term/tty-colors.el (and perhaps elsewhere, where TTY colors are used/defined).
>
> tty-color-standard-values is documented to use the X convention, and
> it does. tty-color-desc is documented to return approximate results,
> and it does;
So we would need to change that as well, no?
> and it's only used for text terminals, right?
Yes, but we nowadays support text terminals that can display 24-bit
colors, and having their colors display differently from the same
color on X is just asking for bug reports.
> > There's also lisp/color.el.
>
> Anything in particular? As far as I can tell, the functions work
> properly using the new convention with this patch, although I am sure
> there are places that fail to deal with the 65280-as-maximum
> convention that nsfns.m uses.
If you convert a color to RGB and then back, is the result equal to
what you started with? E.g., see
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29456#11
Or what about issues discussed in bug#25890 and bug#24273?
> > Am I missing something?
>
> I don't think so, but I don't see anything, so far, that needs
> changing. I'm almost certain that some more places will need changing,
> but how do we find them?
By searching the code for "rgb" (case-insensitively)? E.g., what does
parse_rgb_list return when the RGB value doesn't specify all the bits?
what about color_distance? etc.
My point is that the "old" interpretation of the #RGB values might
have seeped into more places than just that one xterm.c function, and
if we are going to change the interpretation, we should make sure we
do that consistently in all the affected places.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36304
; Package
emacs
.
(Sat, 22 Jun 2019 14:43:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 36304 <at> debbugs.gnu.org (full text, mbox):
On Sat, Jun 22, 2019 at 12:36 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Pip Cet <pipcet <at> gmail.com>
> > Date: Sat, 22 Jun 2019 12:13:20 +0000
> > Cc: rms <at> gnu.org, 36304 <at> debbugs.gnu.org
> >
> > It'd leave us inconsistently still using the X standard in some
> > places, but at first glance they appear to be documented to use the X
> > standard, so maybe that's not wrong.
>
> I'm not sure I understand what you mean by "the X standard". Is that
> the old or the new convention of how to interpret a given #RGB value?
The old convention, of interpreting #f00 as #f00000.
> > > I think we assume this color handling also in xfaces.c
> >
> > Only via tty-color-standard-values, as far as I can see.
> >
> > > and in lisp/term/tty-colors.el (and perhaps elsewhere, where TTY colors are used/defined).
> >
> > tty-color-standard-values is documented to use the X convention, and
> > it does. tty-color-desc is documented to return approximate results,
> > and it does;
>
> So we would need to change that as well, no?
We could. I don't have an opinion either way.
> > and it's only used for text terminals, right?
>
> Yes, but we nowadays support text terminals that can display 24-bit
> colors, and having their colors display differently from the same
> color on X is just asking for bug reports.
Okay, let's change it, then.
> > > There's also lisp/color.el.
> >
> > Anything in particular? As far as I can tell, the functions work
> > properly using the new convention with this patch, although I am sure
> > there are places that fail to deal with the 65280-as-maximum
> > convention that nsfns.m uses.
>
> If you convert a color to RGB and then back, is the result equal to
> what you started with? E.g., see
On my system, yes.
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29456#11
>
> Or what about issues discussed in bug#25890 and bug#24273?
Thanks for pointing me to those. I don't think the situation gets any
worse for those, at least.
> > > Am I missing something?
> >
> > I don't think so, but I don't see anything, so far, that needs
> > changing. I'm almost certain that some more places will need changing,
> > but how do we find them?
>
> By searching the code for "rgb" (case-insensitively)?
I've done that, now. No new problems that I've seen, though
gtkutil.c's xg_get_pixbuf_from_surface confuses me.
> E.g., what does
> parse_rgb_list return when the RGB value doesn't specify all the bits?
> what about color_distance? etc.
Those two are fine, as far as I can see; I know that you meant to
provide only examples, but if you have any hints for finding places
that need changing, please let me know.
> My point is that the "old" interpretation of the #RGB values might
> have seeped into more places than just that one xterm.c function, and
> if we are going to change the interpretation, we should make sure we
> do that consistently in all the affected places.
I don't think there's a way we can be absolutely certain to have fixed
every potential problem, but we should try, yes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36304
; Package
emacs
.
(Sat, 22 Jun 2019 15:06:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 36304 <at> debbugs.gnu.org (full text, mbox):
> From: Pip Cet <pipcet <at> gmail.com>
> Date: Sat, 22 Jun 2019 14:41:30 +0000
> Cc: rms <at> gnu.org, 36304 <at> debbugs.gnu.org
>
> > > > I think we assume this color handling also in xfaces.c
> > >
> > > Only via tty-color-standard-values, as far as I can see.
> > >
> > > > and in lisp/term/tty-colors.el (and perhaps elsewhere, where TTY colors are used/defined).
> > >
> > > tty-color-standard-values is documented to use the X convention, and
> > > it does. tty-color-desc is documented to return approximate results,
> > > and it does;
> >
> > So we would need to change that as well, no?
>
> We could. I don't have an opinion either way.
>
> > > and it's only used for text terminals, right?
> >
> > Yes, but we nowadays support text terminals that can display 24-bit
> > colors, and having their colors display differently from the same
> > color on X is just asking for bug reports.
>
> Okay, let's change it, then.
Thanks.
> > My point is that the "old" interpretation of the #RGB values might
> > have seeped into more places than just that one xterm.c function, and
> > if we are going to change the interpretation, we should make sure we
> > do that consistently in all the affected places.
>
> I don't think there's a way we can be absolutely certain to have fixed
> every potential problem, but we should try, yes.
Of course. I only meant we should fix those we do find. If the only
one is in tty-colors.el, then I guess that's it. The rest will have
to be uncovered as people try using the new code.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36304
; Package
emacs
.
(Sat, 22 Jun 2019 15:34:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 36304 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Jun 22, 2019 at 3:05 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Pip Cet <pipcet <at> gmail.com>
> > Date: Sat, 22 Jun 2019 14:41:30 +0000
> > Cc: rms <at> gnu.org, 36304 <at> debbugs.gnu.org
> > > > and it's only used for text terminals, right?
> > >
> > > Yes, but we nowadays support text terminals that can display 24-bit
> > > colors, and having their colors display differently from the same
> > > color on X is just asking for bug reports.
> > Okay, let's change it, then.
> Thanks.
While I was there, I've also made it accept upper-case hex digits
(previously, #0F0 was accepted but #F00 wasn't), and fixed the ranges
so rgb:f/f/f translates to (65535 65535 65535) rather than (255 255
255).
[0001-Use-CSS-convention-for-interpreting-colors.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36304
; Package
emacs
.
(Fri, 28 Jun 2019 08:14:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 36304 <at> debbugs.gnu.org (full text, mbox):
> From: Pip Cet <pipcet <at> gmail.com>
> Date: Sat, 22 Jun 2019 15:33:14 +0000
> Cc: rms <at> gnu.org, 36304 <at> debbugs.gnu.org
>
> > > > Yes, but we nowadays support text terminals that can display 24-bit
> > > > colors, and having their colors display differently from the same
> > > > color on X is just asking for bug reports.
> > > Okay, let's change it, then.
> > Thanks.
>
> While I was there, I've also made it accept upper-case hex digits
> (previously, #0F0 was accepted but #F00 wasn't), and fixed the ranges
> so rgb:f/f/f translates to (65535 65535 65535) rather than (255 255
> 255).
Thanks.
A few comments:
> * lisp/term/tty-colors.el (tty-color-standard-values): Change
> interpretation of #RGB strings to match CSS rather than X
> conventions. Allow upper-case digits. Fix rgb:R/G/B interpretation.
Our convention is to use two spaces between sentences in documentation
and comments. That includes log entries.
> -The returned value reflects the standard X definition of COLOR,
> +The returned value reflects the standard Emacs definition of COLOR,
This should include some reference to where "standard Emacs
definition" of colors can be found. For X, we didn't need that,
because X docs is not our responsibility, and there's a plenty out
there.
> - (cond ((and (>= len 4) ;; X-style "#XXYYZZ" color spec
> + (cond ((and (>= len 4) ;; "#XXYYZZ" color spec
Is #XXYYZZ no longer considered "X-style"?
> ;; Translate the string "#XXYYZZ" into a list
> - ;; of numbers (XX YY ZZ). If the primary colors
> - ;; are specified with less than 4 hex digits,
> - ;; the used digits represent the most significant
> - ;; bits of the value (e.g. #XYZ = #X000Y000Z000).
> + ;; of numbers (XX YY ZZ). If fewer than 4 hex
> + ;; digits are used, they represent the fraction
> + ;; of the maximum value (#XYZ = #XXXXYYYYZZZZ).
IMO, this part makes the text confusing: "4 hex digits" can be
interpreted as referring to the entire XXYYZZ thing, whereas you
really mean the number of digits for each primary color R, G, and B.
Also, I envision people who will struggle with the exact meaning of
"the fraction of the maximum value". Where the previous text and the
example could be easily generalized to understand how we interpret
#ABCDEF, the proposed text, by giving an example only for a single hex
digit per primary color, does not lend itself to such an easy
generalization.
Finally, this is just part of the patch, isn't it? The xterm.c part
is not here, and neither are the documentation parts. Did I miss
something?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36304
; Package
emacs
.
(Fri, 28 Jun 2019 09:30:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 36304 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Jun 28, 2019 at 8:13 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > While I was there, I've also made it accept upper-case hex digits
> > (previously, #0F0 was accepted but #F00 wasn't), and fixed the ranges
> > so rgb:f/f/f translates to (65535 65535 65535) rather than (255 255
> > 255).
>
> Thanks.
Thanks for the very patient review. Sorry for making so many mistakes.
> > - (cond ((and (>= len 4) ;; X-style "#XXYYZZ" color spec
> > + (cond ((and (>= len 4) ;; "#XXYYZZ" color spec
>
> Is #XXYYZZ no longer considered "X-style"?
I would say no, since X's interpretation of #f00 is a little different
from the HTML/CSS/SVG interpretation.
> > ;; Translate the string "#XXYYZZ" into a list
> > - ;; of numbers (XX YY ZZ). If the primary colors
> > - ;; are specified with less than 4 hex digits,
> > - ;; the used digits represent the most significant
> > - ;; bits of the value (e.g. #XYZ = #X000Y000Z000).
> > + ;; of numbers (XX YY ZZ). If fewer than 4 hex
> > + ;; digits are used, they represent the fraction
> > + ;; of the maximum value (#XYZ = #XXXXYYYYZZZZ).
>
> IMO, this part makes the text confusing:
Thanks, you're absolutely right.
> Finally, this is just part of the patch, isn't it? The xterm.c part
> is not here, and neither are the documentation parts. Did I miss
> something?
Complete updated patch attached.
[0001-Use-the-CSS-convention-for-RGB-colors-bug-36304.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36304
; Package
emacs
.
(Fri, 28 Jun 2019 09:43:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 36304 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 28 Jun 2019 09:28:53 +0000, Pip Cet <pipcet <at> gmail.com> said:
Pip> Complete updated patch attached.
As someone willfully and woefully ignorant of Emacs' colour handling,
I gave this patch a read, and I find it perfectly clear. One very
minor nit below (which was there before this patch)
Pip> @@ -978,7 +982,7 @@ tty-color-translate
Pip> "Given a color COLOR, return the index of the corresponding TTY color.
Pip> COLOR must be a string that is either the color's name, or its X-style
Pip> -specification like \"#RRGGBB\" or \"RGB:rr/gg/bb\", where each primary.
Pip> +specification like \"#RRGGBB\" or \"rgb:RR/GG/BB\", where each primary.
Thereʼs an extra '.' at the end of this line.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36304
; Package
emacs
.
(Fri, 28 Jun 2019 10:02:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 36304 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Jun 28, 2019 at 9:42 AM Robert Pluim <rpluim <at> gmail.com> wrote:
> Pip> COLOR must be a string that is either the color's name, or its X-style
> Pip> -specification like \"#RRGGBB\" or \"RGB:rr/gg/bb\", where each primary.
> Pip> +specification like \"#RRGGBB\" or \"rgb:RR/GG/BB\", where each primary.
>
> Thereʼs an extra '.' at the end of this line.
Thanks!
I also spotted some more references to X in the docstrings.
Updated patch attached. Please let me know if you notice anything
else in there that needs changing.
[0001-Use-the-CSS-convention-for-RGB-colors-bug-36304.patch (application/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36304
; Package
emacs
.
(Fri, 28 Jun 2019 12:51:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 36304 <at> debbugs.gnu.org (full text, mbox):
> From: Pip Cet <pipcet <at> gmail.com>
> Date: Fri, 28 Jun 2019 09:28:53 +0000
> Cc: rms <at> gnu.org, 36304 <at> debbugs.gnu.org
>
> > > - (cond ((and (>= len 4) ;; X-style "#XXYYZZ" color spec
> > > + (cond ((and (>= len 4) ;; "#XXYYZZ" color spec
> >
> > Is #XXYYZZ no longer considered "X-style"?
>
> I would say no, since X's interpretation of #f00 is a little different
> from the HTML/CSS/SVG interpretation.
Then maybe we want to refer to HTML/CSS/SVG?
> Complete updated patch attached.
LGTM, with one comment:
> +The returned value reflects the standard Emacs definition of
> +COLOR (see `Colors for Faces' in the Emacs manual), regardless of
Our convention is to say
see the Info node `(emacs) Colors for Faces'
to refer to the Info manual.
Also, I think this change warrants an entry in NEWS.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36304
; Package
emacs
.
(Fri, 28 Jun 2019 13:08:01 GMT)
Full text and
rfc822 format available.
Message #47 received at submit <at> debbugs.gnu.org (full text, mbox):
On Fri 28 Jun 2019, Pip Cet wrote:
> Updated patch attached. Please let me know if you notice anything
> else in there that needs changing.
As this changes user-visible behaviour it should probably have a NEWS entry.
> @@ -2398,9 +2400,35 @@ x_query_frame_background_color (struct frame *f, XColor *bgcolor)
>
> if (color_name[0] == '#')
> {
> - /* The hex form is parsed directly by XParseColor without
> + /* Don't pass #RGB strings directly to XParseColor, because that
> + follows the old convention of zero-extending each channel
> + value: #f00 means #f00000. We want the new convention of
> + scaling channel values, so #f00 means #ff0000.
> +
> + So we translate #f00 to rgb:f/0/0, which X handles
> + differently. */
The use of "old" and "new" here is unclear.
Consider "old" -> "X" and "new" -> "emacs".
AndyM
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36304
; Package
emacs
.
(Fri, 28 Jun 2019 14:35:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 36304 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Then maybe we want to refer to HTML/CSS/SVG?
Sounds good.
> Our convention is to say
>
> see the Info node `(emacs) Colors for Faces'
>
> to refer to the Info manual.
Thanks! I was looking for that syntax :-)
> Also, I think this change warrants an entry in NEWS.
Okay.
This patch also incorporates Andy's suggestions, and adds some tests.
[0001-Use-the-CSS-convention-for-RGB-colors-bug-36304.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36304
; Package
emacs
.
(Fri, 28 Jun 2019 19:55:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 36304 <at> debbugs.gnu.org (full text, mbox):
> From: Pip Cet <pipcet <at> gmail.com>
> Date: Fri, 28 Jun 2019 14:34:03 +0000
> Cc: rms <at> gnu.org, 36304 <at> debbugs.gnu.org
>
> This patch also incorporates Andy's suggestions, and adds some tests.
LGTM, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36304
; Package
emacs
.
(Fri, 28 Jun 2019 21:28:01 GMT)
Full text and
rfc822 format available.
Message #56 received at submit <at> debbugs.gnu.org (full text, mbox):
On Fri 28 Jun 2019, Pip Cet wrote:
> This patch also incorporates Andy's suggestions, and adds some tests.
There is an unintended change to src/atimer.c, but otherwise looks good.
AndyM
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#36304
; Package
emacs
.
(Mon, 22 Jul 2019 02:47:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 36304 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Jun 28, 2019 at 9:28 PM Andy Moreton <andrewjmoreton <at> gmail.com> wrote:
> On Fri 28 Jun 2019, Pip Cet wrote:
>
> > This patch also incorporates Andy's suggestions, and adds some tests.
>
> There is an unintended change to src/atimer.c, but otherwise looks good.
Rebased and revised patch attached.
[0001-Use-the-CSS-convention-for-RGB-colors-bug-36304.patch (text/x-patch, attachment)]
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Sat, 27 Jul 2019 11:14:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Pip Cet <pipcet <at> gmail.com>
:
bug acknowledged by developer.
(Sat, 27 Jul 2019 11:14:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 36304-done <at> debbugs.gnu.org (full text, mbox):
> From: Pip Cet <pipcet <at> gmail.com>
> Date: Mon, 22 Jul 2019 02:46:16 +0000
> Cc: 36304 <at> debbugs.gnu.org
>
> Rebased and revised patch attached.
Thanks, pushed to the master branch.
Note that the test file wasn't in the correct directory; I moved it.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 24 Aug 2019 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 238 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.