On Fri, Mar 20, 2009 at 03:13:53PM -0400, Allan Caffee wrote:
> /*
> * 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
--
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
