Re: [PATCH 5/7] parse_color: support 24-bit RGB values
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Nov 20, 2014, 19:44 UTC
- Message-ID
- <xmqqh9xt3bdx.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <20141120152539.GE23680@peff.net>
Jeff King <peff@peff.net> writes:
Show 60 quoted lines
> 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.