Jeff King <peff@xxxxxxxx> 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@xxxxxxxx>
> ---
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html