git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 16, 2020, 18:01 UTC
Message-ID
<xmqq5zhbi8l3.fsf@gitster-ct.c.googlers.com>
In-Reply-To
<20200110150547.221314-1-shawarmakarma@gmail.com>
Eyal Soha <shawarmakarma@gmail.com> writes:

This space looks a bit underexplained. I cannot tell, for example, if the changes to out->value this patch makes (i.e. in COLOR_ANSI mode, we used to use 0-7, but now it is offset to 30-37) is intended.

It is especially confusing that parse_color() stuffs 30-37 in the .value field for COLOR_ANSI mode, and then color_output() takes a struct color and then uses xsnprintf() on .value PLUS offset. The offset used to be "type" that was either "3" or "4", and now it is either 0 or 10 (= COLOR_BACKGROUND_OFFSET), so it cancels out, but when this step is viewed alone, it is not clear why the updated code does not use 0-7 in .value and 30 or 40 in the offset, which is more in line with how the original code worked.

In any case, "COLOR_BACKGROUND_OFFSET = 10" needs to be commented much better---something like "In 'struct color', we chose to represent the color value in the .value field with the ANSI foreground color number between 30 and 37, and adding this offset value makes the color to their background counterparts".

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.

Show 21 quoted lines
> +enum {
> +	COLOR_BACKGROUND_OFFSET = 10,
> +	COLOR_FOREGROUND_ANSI = 30,
> +	COLOR_FOREGROUND_RGB = 38,
> +	COLOR_FOREGROUND_256 = 38,
> +};
> +
>  /* Ignore the RESET at the end when giving the size */
>  const int column_colors_ansi_max = ARRAY_SIZE(column_colors_ansi) - 1;
>  
> @@ -92,7 +99,7 @@ static int parse_color(struct color *out, const char *name, int len)
>  	for (i = 0; i < ARRAY_SIZE(color_names); i++) {
>  		if (match_word(name, len, color_names[i])) {
>  			out->type = COLOR_ANSI;
> -			out->value = i;
> +			out->value = i + COLOR_FOREGROUND_ANSI;
>  			return 0;
>  		}
>  	}
> @@ -112,7 +119,7 @@ static int parse_color(struct color *out, const char *name, int len)
>  		/* Rewrite low numbers as more-portable standard colors. */

This comment, being in the context, obviously is not a new problem introduced by this patch, but my reading hiccupped on the verb "rewrite"---what are we rewriting?---and had to read the logic twice to realize that this comment is about choosing COLOR_ANSI over COLOR_256 (i.e. we assume ANSI is more prevalent than 256, so any color expressible in both is better shown using ANSI). Perhaps

		/* Express low numbers in basic ANSI rather than 256 */
or something may have been easier to understand at least to me.
Thanks.
Show 53 quoted lines
>  		} else if (val < 8) {
>  			out->type = COLOR_ANSI;
> -			out->value = val;
> +			out->value = val + COLOR_FOREGROUND_ANSI;
>  			return 0;
>  		} else if (val < 256) {
>  			out->type = COLOR_256;
> @@ -166,23 +173,22 @@ int color_parse(const char *value, char *dst)
>   * already have the ANSI escape code in it. "out" should have enough
>   * space in it to fit any color.
>   */
> -static char *color_output(char *out, int len, const struct color *c, char type)
> +static char *color_output(char *out, int len, const struct color *c, int offset)
>  {
>  	switch (c->type) {
>  	case COLOR_UNSPECIFIED:
>  	case COLOR_NORMAL:
>  		break;
>  	case COLOR_ANSI:
> -		if (len < 2)
> -			BUG("color parsing ran out of space");
> -		*out++ = type;
> -		*out++ = '0' + c->value;
> +		out += xsnprintf(out, len, "%d", c->value + offset);
>  		break;
>  	case COLOR_256:
> -		out += xsnprintf(out, len, "%c8;5;%d", type, c->value);
> +		out += xsnprintf(out, len, "%d;5;%d", COLOR_FOREGROUND_256 + offset,
> +				 c->value);
>  		break;
>  	case COLOR_RGB:
> -		out += xsnprintf(out, len, "%c8;2;%d;%d;%d", type,
> +		out += xsnprintf(out, len, "%d;2;%d;%d;%d",
> +				 COLOR_FOREGROUND_RGB + offset,
>  				 c->red, c->green, c->blue);
>  		break;
>  	}
> @@ -280,13 +286,13 @@ int color_parse_mem(const char *value, int value_len, char *dst)
>  			if (sep++)
>  				OUT(';');
>  			/* foreground colors are all in the 3x range */
> -			dst = color_output(dst, end - dst, &fg, '3');
> +			dst = color_output(dst, end - dst, &fg, 0);
>  		}
>  		if (!color_empty(&bg)) {
>  			if (sep++)
>  				OUT(';');
>  			/* background colors are all in the 4x range */
> -			dst = color_output(dst, end - dst, &bg, '4');
> +			dst = color_output(dst, end - dst, &bg, COLOR_BACKGROUND_OFFSET);
>  		}
>  		OUT('m');
>  	}
Previous: Jeff KingNext: Jeff King
Message 13 of 37 in “Fwd: Add support for axiterm colors in parse_color”
  1. Eyal SohaJan 7, 2020
  2. Jeff KingJan 8, 2020
  3. Eyal SohaJan 10, 2020
  4. Jeff KingJan 10, 2020
  5. Eyal SohaJan 10, 2020
  6. Eyal SohaJan 15, 2020
  7. 1/3 color.c: Refactor color_output to use enumsEyal Soha, Jan 10, 2020
  8. 2/3 color.c: Support bright aixterm colorsEyal Soha, Jan 10, 2020
  9. Jeff KingJan 15, 2020
  10. 3/3 color.c: Alias RGB colors 8-15 to aixterm colorsEyal Soha, Jan 10, 2020
  11. Jeff KingJan 15, 2020
  12. Jeff KingJan 15, 2020
  13. Junio C HamanoJan 16, 2020
  14. Jeff KingJan 16, 2020
  15. Eyal SohaJan 16, 2020
  16. 1/3 color.c: Refactor color_output to use enumsEyal Soha, Jan 18, 2020
  17. 2/3 color.c: Support bright aixterm colorsEyal Soha, Jan 18, 2020
  18. Junio C HamanoJan 18, 2020
  19. Eyal SohaJan 21, 2020
  20. 1/3 color.c: refactor color_output argumentsEyal Soha, Jan 21, 2020
  21. 2/3 color.c: support bright aixterm colorsEyal Soha, Jan 21, 2020
  22. Junio C HamanoJan 23, 2020
  23. 3/3 color.c: alias RGB colors 8-15 to aixterm colorsEyal Soha, Jan 21, 2020
  24. Junio C HamanoJan 23, 2020
  25. 0/3 es/bright-colors (hopefully final) rerollJunio C Hamano, Feb 11, 2020
  26. 2/3 color.c: support bright aixterm colorsJunio C Hamano, Feb 11, 2020
  27. 3/3 color.c: alias RGB colors 8-15 to aixterm colorsJunio C Hamano, Feb 11, 2020
  28. 1/3 color.c: refactor color_output argumentsJunio C Hamano, Feb 11, 2020
  29. Jeff KingFeb 11, 2020
  30. Eyal SohaFeb 11, 2020
  31. Junio C HamanoFeb 11, 2020
  32. Junio C HamanoJan 21, 2020
  33. 3/3 color.c: Alias RGB colors 8-15 to aixterm colorsEyal Soha, Jan 18, 2020
  34. Junio C HamanoJan 18, 2020
  35. Junio C HamanoJan 18, 2020
  36. Eyal SohaJan 21, 2020
  37. Junio C HamanoJan 21, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.