Re: [PATCH 1/3] color.c: Refactor color_output to use enums

From: Eyal Soha <shawarmakarma@gmail.com>
Date: Jan 16, 2020, 19:25 UTC
Message-ID: <CANsz78JyawDpp_SewRQp4_AbZVduSYiazhvCqUcqUV810az5MQ@mail.gmail.com>
In-Reply-To: <20200116182331.GA2946050@coredump.intra.peff.net>

My original version of the change extended the enum to include both COLOR_ANSI and COLOR_AIXTERM. That preserves the 0-7 value and instead adds more branching to figure out if you want to add 30 or 40 or 90 or 100. All that extra branching didn't look great so we instead used COLOR_ANSI for both.

I think that adding a bright flag to the color struct would be a poor choice because it doesn't mean anything in the context of COLOR_256 and COLOR_RGB, as you've pointed out.

Having an argument to the color_output function called "type" that is a char is really obtuse, especially considering that c->type exists, too! Perhaps the best way would really be to have a boolean argument called "background" indicating if the color is meant to be foreground or background and then let color_output do the math to add or not add 10.

Thoughts?

Eyal

Eyal

On Thu, Jan 16, 2020 at 1:23 PM Jeff King <peff@peff.net> wrote:

Show 25 quoted lines

>
> On Thu, Jan 16, 2020 at 10:01:44AM -0800, Junio C Hamano wrote:
>
> > Not that I agree with the (untold) reasoning why we chose to use
> > 30-37 instead of 0-7, though.  If this were up to me, I would have
> > rather defined COLOR_BACKGROUND_ANSI = 40, kept .value to 0-7 and
> > passed COLOR_{FORE,BACK}GROUPD_ANSI to callers of color_output().
> >
> > Since I haven't seen 2/3 and 3/3, perhaps there is a good reason why
> > this step was done this way instead, though, I guess.
>
> Yeah, it becomes more clear in patch 2, where the value can be either
> "31" or "91", for the bright or non-bright variant, and adding "30" is
> wrong. (But certainly I agree this needs to be explained here).
>
> Another way to write it would be to store 0-7 in the value as before,
> and then add a separate "bright" flag to "struct color". And then the
> output becomes:
>
>   COLOR_FOREGROUND_OFFSET + c->value + (c->bright ? COLOR_BRIGHT_OFFSET : 0)
>
> or similar. One minor confusion there is that COLOR_256 and COLOR_RGB
> would ignore the "bright" field.
>
> -Peff