Re: [RFC] Colorization of log --graph

From: Jeff King <peff@peff.net>
Date: Mar 20, 2009, 19:58 UTC
Message-ID: <20090320195806.GC26934@coredump.intra.peff.net>
In-Reply-To: <b2e43f8f0903201213o396de6c0sb52149ed1d889d1@mail.gmail.com>

On Fri, Mar 20, 2009 at 03:13:53PM -0400, Allan Caffee wrote:

Show 17 quoted lines

> /*
>  * Map names to ANSI escape sequences.  Consider putting this in color.c
>  * and providing color_name_get_ansi_code(enum color_name).
>  */
> const char* git_color_codes[] {
> 	GIT_COLOR_RESET,
> 	GIT_COLOR_BOLD,
> 	GIT_COLOR_RED,
> 	GIT_COLOR_GREEN,
> 	GIT_COLOR_YELLOW,
> 	GIT_COLOR_BLUE,
> 	GIT_COLOR_CYAN,
> 	GIT_COLOR_BG_RED,
> };
> 
> That conveniently offers clients access to both the raw escape codes and
> a clear type for storing/handling colors.

I want to point out one thing: an enum or a list like this is actually a subset of the useful color codes that git can represent. Actual configured colors can have attributes, foreground, and background colors. So they need to be stored in a character array.

Adding an enum for GIT_COLOR_RED and using it throughout the code can be helpful for simple cases, but it doesn't give you an easy way of saying "red background, blue foreground". Maybe that is enough for git internal usage, since we tend not to use backgrounds or attributes for defaults. But maybe it makes more sense to do this as:

  const char *ansi_color(enum color fg, enum color bg, enum attribute attr);

and return a pointer to a static array representing the color (and even cycle through a list the way sha1_to_hex or git_path does). And you could even use it to simplify and share code with the config color parsing in color.c.

-Peff