[PATCH 0/2] color: support "default" to restore fg/bg color

[PATCH 0/2] color: support "default" to restore fg/bg color

[Robert Estelle via GitGitGadget]

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

[PATCH 1/2] color: add missing GIT_COLOR_* white/black constants

[Robert Estelle via GitGitGadget]

From: Robert Estelle <robertestelle@gmail.com>

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.

Signed-off-by: Robert Estelle <robertestelle@gmail.com>
---
 color.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/color.h b/color.h
index 98894d6a175..c20d324e7ca 100644
--- a/color.h
+++ b/color.h
@@ -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

[PATCH 2/2] color: support "default" to restore fg/bg color

[Robert Estelle via GitGitGadget]

From: Robert Estelle <robertestelle@gmail.com>

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).

Signed-off-by: Robert Estelle <robertestelle@gmail.com>
---
 Documentation/config.txt | 18 +++++++++++++-----
 color.c                  | 23 ++++++++++++++++++++++-
 color.h                  |  4 ++++
 t/t4026-color.sh         | 12 ++++++++++++
 4 files changed, 51 insertions(+), 6 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index bf82766a6a2..78f13f061e5 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -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
diff --git a/color.c b/color.c
index 64f52a4f93a..a5fa9b79a7a 100644
--- a/color.c
+++ b/color.c
@@ -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;
diff --git a/color.h b/color.h
index c20d324e7ca..27e817016bf 100644
--- a/color.h
+++ b/color.h
@@ -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"
diff --git a/t/t4026-color.sh b/t/t4026-color.sh
index c0b642c1ab0..e34838ded95 100755
--- a/t/t4026-color.sh
+++ b/t/t4026-color.sh
@@ -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

Re: [PATCH 2/2] color: support "default" to restore fg/bg color

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

On 2021-10-25 at 22:32:36, Robert Estelle via GitGitGadget wrote:
> From: Robert Estelle <robertestelle@gmail.com>
> 
> 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).

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [PATCH 2/2] color: support "default" to restore fg/bg color

[Junio C Hamano]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> 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.

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.

Re: [PATCH 2/2] color: support "default" to restore fg/bg color

[Robert Estelle]

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

On Mon, Oct 25, 2021 at 3:49 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>
> > 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.
>
> 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.

Re: [PATCH 2/2] color: support "default" to restore fg/bg color

[Junio C Hamano]

Robert Estelle <robertestelle@gmail.com> writes:

> 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).

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.

Re: [PATCH 2/2] color: support "default" to restore fg/bg color

[Robert Estelle]

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. 

> On Oct 28, 2021, at 9:41 AM, Junio C Hamano <gitster@pobox.com> wrote:
> 
> Robert Estelle <robertestelle@gmail.com> writes:
> 
>> 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).
> 
> 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.