Re: [PATCH 5/7] parse_color: support 24-bit RGB values

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> Some terminals (like XTerm) allow full 24-bit RGB color
> specifications using an extension to the regular ANSI color
> scheme. Let's allow users to specify hex RGB colors,
> enabling the all-important feature of hot pink ref
> decorations:
>
>   git log --format="%h%C(#ff69b4)%d%C(reset) %s"
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> Also no clue on which terminals support it. I did all of my testing on
> a recent version of XTerm. It looks like it doesn't provide true 24-bit
> support, though. It is happy to accept the 24-bit colors, but if you do:
>
>   for b in $(seq 255); do
>     h=$(printf %02x $b)
>     git --no-pager log -1 --format="%C(#0000$h)$b%C(reset)"
>   done
>
> the gradient seems to "jump" in discrete steps. That's fine, though.
> It's a quality-of-implementation issue for the terminal, and I still
> think that the RGB spec is way more readable than the 256-color mode
> ones.
>
>  Documentation/config.txt |  3 ++-
>  color.c                  | 29 ++++++++++++++++++++++++++++-
>  color.h                  |  6 +++---
>  t/t4026-color.sh         |  4 ++++
>  4 files changed, 37 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index f615a5c..a237b82 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -842,7 +842,8 @@ doesn't matter.
>  +
>  Colors (foreground and background) may also be given as numbers between
>  0 and 255; these use ANSI 256-color mode (but note that not all
> -terminals may support this).
> +terminals may support this).  If your terminal supports it, you may also
> +specify 24-bit RGB values as hex, like `#ff0ab3`.
>  
>  color.diff::
>  	Whether to use ANSI escape sequences to add color to patches.
> diff --git a/color.c b/color.c
> index 6edbcae..78cdbed 100644
> --- a/color.c
> +++ b/color.c
> @@ -32,10 +32,13 @@ struct color {
>  		COLOR_UNSPECIFIED = 0,
>  		COLOR_NORMAL,
>  		COLOR_ANSI, /* basic 0-7 ANSI colors */
> -		COLOR_256
> +		COLOR_256,
> +		COLOR_RGB
>  	} state;
>  	/* The numeric value for ANSI and 256-color modes */
>  	unsigned char value;
> +	/* 24-bit RGB color values */
> +	unsigned char red, green, blue;

Do value and rgb have to be both valid at the same time, or is this
"we are not wasting a byte by not using a union because it will be
in the padding of the outer struct anyway"?

Not a satirical and/or rhetorical question.