color: support "default" to restore fg/bg color

The name "default" can now be used in foreground or background colors, and means to use the terminal's default color, discarding any explicitly-set color without affecting the other attributes. On many modern terminals, this is not the same as specifying "white" or "black".

Although attributes could previously be cleared like "no-bold", there had not been a similar mechanism available for colors, other than a full "reset", which cannot currently be combined with post-reset settings.

Note that this is not the same as the existing name "normal", which is a no-op placeholder to permit setting the background without changing the foreground. (i.e. what is currently called "normal" might have been more descriptively named "inherit", "none", "pass" or similar).

Robert Estelle (2):
color: add missing GIT_COLOR_* white/black constants
color: support "default" to restore fg/bg color

 Documentation/config.txt | 18 +++++++++++++-----
 color.c                  | 23 ++++++++++++++++++++++-
 color.h                  | 12 ++++++++++++
 t/t4026-color.sh         | 12 ++++++++++++
 4 files changed, 59 insertions(+), 6 deletions(-)

base-commit: 225bc32a989d7a22fa6addafd4ce7dcd04675dbf
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1116%2Frwe%2Fansi-default-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1116/rwe/ansi-default-v1
Pull-Request: https://github.com/git/git/pull/1116

gitgitgadget

From: Robert Estelle <[email protected]>

The colors black and white where conspicuously missing from the color constants. Although they are not currently used in the codebase, having them included makes it easier to visually verify the ANSI codes, and to distinguish them explicitly from "GIT_COLOR_DEFAULT" in a subsequent change.

---
 color.h | 8 ++++++++
 1 file changed, 8 insertions(+)

index 98894d6a175..c20d324e7ca 100644
@@ -24,30 +24,38 @@ struct strbuf;
 #define GIT_COLOR_NORMAL	""
 #define GIT_COLOR_RESET		"\033[m"
 #define GIT_COLOR_BOLD		"\033[1m"
+#define GIT_COLOR_BLACK		"\033[30m"
 #define GIT_COLOR_RED		"\033[31m"
 #define GIT_COLOR_GREEN		"\033[32m"
 #define GIT_COLOR_YELLOW	"\033[33m"
 #define GIT_COLOR_BLUE		"\033[34m"
 #define GIT_COLOR_MAGENTA	"\033[35m"
 #define GIT_COLOR_CYAN		"\033[36m"
+#define GIT_COLOR_WHITE		"\033[37m"
+#define GIT_COLOR_BOLD_BLACK	"\033[1;30m"
 #define GIT_COLOR_BOLD_RED	"\033[1;31m"
 #define GIT_COLOR_BOLD_GREEN	"\033[1;32m"
 #define GIT_COLOR_BOLD_YELLOW	"\033[1;33m"
 #define GIT_COLOR_BOLD_BLUE	"\033[1;34m"
 #define GIT_COLOR_BOLD_MAGENTA	"\033[1;35m"
 #define GIT_COLOR_BOLD_CYAN	"\033[1;36m"
+#define GIT_COLOR_BOLD_WHITE	"\033[1;37m"
+#define GIT_COLOR_FAINT_BLACK	"\033[2;30m"
 #define GIT_COLOR_FAINT_RED	"\033[2;31m"
 #define GIT_COLOR_FAINT_GREEN	"\033[2;32m"
 #define GIT_COLOR_FAINT_YELLOW	"\033[2;33m"
 #define GIT_COLOR_FAINT_BLUE	"\033[2;34m"
 #define GIT_COLOR_FAINT_MAGENTA	"\033[2;35m"
 #define GIT_COLOR_FAINT_CYAN	"\033[2;36m"
+#define GIT_COLOR_FAINT_WHITE	"\033[2;37m"
+#define GIT_COLOR_BG_BLACK	"\033[40m"
 #define GIT_COLOR_BG_RED	"\033[41m"
 #define GIT_COLOR_BG_GREEN	"\033[42m"
 #define GIT_COLOR_BG_YELLOW	"\033[43m"
 #define GIT_COLOR_BG_BLUE	"\033[44m"
 #define GIT_COLOR_BG_MAGENTA	"\033[45m"
 #define GIT_COLOR_BG_CYAN	"\033[46m"
+#define GIT_COLOR_BG_WHITE	"\033[47m"
 #define GIT_COLOR_FAINT		"\033[2m"
 #define GIT_COLOR_FAINT_ITALIC	"\033[2;3m"
 #define GIT_COLOR_REVERSE	"\033[7m"

gitgitgadget

From: Robert Estelle <[email protected]>

The name "default" can now be used in foreground or background colors, and means to use the terminal's default color, discarding any explicitly-set color without affecting the other attributes. On many modern terminals, this is *not* the same as specifying "white" or "black".

Although attributes could previously be cleared like "no-bold", there had not been a similar mechanism available for colors, other than a full "reset", which cannot currently be combined with other settings.

Note that this is *not* the same as the existing name "normal", which is a no-op placeholder to permit setting the background without changing the foreground. (i.e. what is currently called "normal" might have been more descriptively named "inherit", "none", "pass" or similar).

---
 Documentation/config.txt | 18 +++++++++++++-----
 color.c                  | 23 ++++++++++++++++++++++-
 color.h                  |  4 ++++
 t/t4026-color.sh         | 12 ++++++++++++
 4 files changed, 51 insertions(+), 6 deletions(-)

index bf82766a6a2..78f13f061e5 100644
@@ -262,11 +262,19 @@ color::
        colors (at most two, one for foreground and one for background)
        and attributes (as many as you want), separated by spaces.
 +
-The basic colors accepted are `normal`, `black`, `red`, `green`, `yellow`,
-`blue`, `magenta`, `cyan` and `white`.  The first color given is the
-foreground; the second is the background.  All the basic colors except
-`normal` have a bright variant that can be specified by prefixing the
-color with `bright`, like `brightred`.
+The basic colors accepted are `normal`, `black`, `red`, `green`,
+`yellow`, `blue`, `magenta`, `cyan`, `white` and `default`.  The first
+color given is the foreground; the second is the background.  All the
+basic colors except `normal` and `default` have a bright variant that can
+be specified by prefixing the color with `bright`, like `brightred`.
++
+The color `normal` makes no change to the color. It is the same as an
+empty string, but can be used as the foreground color when specifying a
+background color alone (for example, "normal red").
++
+The color `default` explicitly resets the color to the terminal default,
+for example to specify a cleared background. Although it varies between
+terminals, this is usually not the same as setting to "white black".
 +
 Colors 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).  If

index 64f52a4f93a..a5fa9b79a7a 100644
@@ -40,7 +40,7 @@ struct color {
 	enum {
 		COLOR_UNSPECIFIED = 0,
 		COLOR_NORMAL,
-		COLOR_ANSI, /* basic 0-7 ANSI colors */
+		COLOR_ANSI, /* basic 0-7 ANSI colors + "default" (value = 9) */
 		COLOR_256,
 		COLOR_RGB
 	} type;

@@ -83,6 +83,27 @@ static int parse_ansi_color(struct color *out, const char *name, int len)
 	int i;
 	int color_offset = COLOR_FOREGROUND_ANSI;
 
+	if (match_word(name, len, "default")) {
+		/*
+		 * Restores to the terminal's default color, which may not be
+		 * the same as explicitly setting "white" or "black".
+		 *
+		 * ECMA-48 - Control Functions \
+		 *  for Coded Character Sets, 5th edition (June 1991):
+		 * > 39 default display colour (implementation-defined)
+		 * > 49 default background colour (implementation-defined)
+		 *
+		 * Although not supported /everywhere/--according to terminfo,
+		 * some terminals define "op" (original pair) as a blunt
+		 * "set to white on black", or even "send full SGR reset"--
+		 * it's standard and well-supported enough that if a user
+		 * asks for it in their config this will do the right thing.
+		 */
+		out->type = COLOR_ANSI;
+		out->value = 9 + color_offset;
+		return 0;
+	}
+
 	if (strncasecmp(name, "bright", 6) == 0) {
 		color_offset = COLOR_FOREGROUND_BRIGHT_ANSI;
 		name += 6;

index c20d324e7ca..27e817016bf 100644
@@ -32,6 +32,7 @@ struct strbuf;
 #define GIT_COLOR_MAGENTA	"\033[35m"
 #define GIT_COLOR_CYAN		"\033[36m"
 #define GIT_COLOR_WHITE		"\033[37m"
+#define GIT_COLOR_DEFAULT	"\033[39m"
 #define GIT_COLOR_BOLD_BLACK	"\033[1;30m"
 #define GIT_COLOR_BOLD_RED	"\033[1;31m"
 #define GIT_COLOR_BOLD_GREEN	"\033[1;32m"

@@ -40,6 +41,7 @@ struct strbuf;
 #define GIT_COLOR_BOLD_MAGENTA	"\033[1;35m"
 #define GIT_COLOR_BOLD_CYAN	"\033[1;36m"
 #define GIT_COLOR_BOLD_WHITE	"\033[1;37m"
+#define GIT_COLOR_BOLD_DEFAULT	"\033[1;39m"
 #define GIT_COLOR_FAINT_BLACK	"\033[2;30m"
 #define GIT_COLOR_FAINT_RED	"\033[2;31m"
 #define GIT_COLOR_FAINT_GREEN	"\033[2;32m"

@@ -48,6 +50,7 @@ struct strbuf;
 #define GIT_COLOR_FAINT_MAGENTA	"\033[2;35m"
 #define GIT_COLOR_FAINT_CYAN	"\033[2;36m"
 #define GIT_COLOR_FAINT_WHITE	"\033[2;37m"
+#define GIT_COLOR_FAINT_DEFAULT	"\033[2;39m"
 #define GIT_COLOR_BG_BLACK	"\033[40m"
 #define GIT_COLOR_BG_RED	"\033[41m"
 #define GIT_COLOR_BG_GREEN	"\033[42m"

@@ -56,6 +59,7 @@ struct strbuf;
 #define GIT_COLOR_BG_MAGENTA	"\033[45m"
 #define GIT_COLOR_BG_CYAN	"\033[46m"
 #define GIT_COLOR_BG_WHITE	"\033[47m"
+#define GIT_COLOR_BG_DEFAULT	"\033[49m"
 #define GIT_COLOR_FAINT		"\033[2m"
 #define GIT_COLOR_FAINT_ITALIC	"\033[2;3m"
 #define GIT_COLOR_REVERSE	"\033[7m"

index c0b642c1ab0..e34838ded95 100755
@@ -94,6 +94,18 @@ test_expect_success '24-bit colors' '
 	color "#ff00ff black" "[38;2;255;0;255;40m"
 '
 
+test_expect_success '"default" foreground' '
+	color "default" "[39m"
+'
+
+test_expect_success '"normal default" to clear background' '
+	color "normal default" "[49m"
+'
+
+test_expect_success '"default" can be combined with attributes' '
+	color "default default no-reverse bold" "[1;27;39;49m"
+'
+
 test_expect_success '"normal" yields no color at all"' '
 	color "normal black" "[40m"
 '

gitgitgadget

I can't speak to whether this is correct, although you did mention the standard, so I assume it is, but I do think this is a good feature to have and the patch seems sane to me. Patch 2 also looked good here.

For an example of why this differs from white on black, let me mention that I use a semi-transparent terminal, where a black background is opaque black, and the default is semi-transparent. I assume other possibilities include patterned backgrounds (Enlightenment, anyone?). Whether you want to include something to this effect in the commit message is up to you, but I provide it for the interested reader.

brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

It would help support the description of the cause, I would think.

I am also OK with these changes. [1/2] is good for completeness, and being able to say "go back to the default" without having to know what the default is with [2/2] is also a good change.

Thanks, both.

Those are good examples. Note that this applies to more cases than those relying on transparency or patterns: color terms often have defaults that are not identical to their ANSI palette. I suspect *most* themes are probably this way, based on a quick sampling.

You can see a bunch of examples here:
https://github.com/mbadolato/iTerm2-Color-Schemes#screenshots in all the themes where the background color in the "40m" column isn't the same as the unset column before it. (All of Terminal.app's built-in themes are that way; I know xterm defaults to black on white vs white on black; and so on).

Best,
Robert

I think you are wasting your time giving these to _us_ on the list who happen to already understand what the issue you are attempting to fix with these patches. The suggestion was that you would help future readers of "git log" if you wrote even just one or a few of them in your proposed log message. Those who will be digging the history, perhaps they want to fix something in near-by code, may not be aware of this discussion but the log message is a good place to leave a note for them.

Thanks.

Sure. I can update the commit message. Both the commit message and the doc update already described that the default is terminal dependent and frequently not white on black, and the doc update gave transparent as an example. I expected that to be clear enough, but I can add more background.