Am 09.10.2016 um 12:04 schrieb Tom Hale:
> On 2016-10-09 13:47, René Scharfe wrote:
>
>> %Cgreen emits color codes unconditionally. %C(auto,green) would respect
>> the config settings.
>
> Thanks, I've never seen the (,) syntax documented before!
Both the prefix "auto," for terminal-detection and "%C(auto)" for
choosing colors automatically are mentioned in the manpage for git log
(from Documentation/pretty-formats.txt):
- '%C(...)': color specification, as described in color.branch.* config option;
adding `auto,` at the beginning will emit color only when colors are
enabled for log output (by `color.diff`, `color.ui`, or `--color`, and
respecting the `auto` settings of the former if we are going to a
terminal). `auto` alone (i.e. `%C(auto)`) will turn on auto coloring
on the next placeholders until the color is switched again.
> What's strange is that this works:
> %C(auto,green bold)
> but
> %C(auto,green,bold)
> does not.
Looking at the code that's not surprising; colors and attributes are
interpreted as a space-separated list. The prefix "auto," is handled
specially. For a user it may look strange, admittedly.
Supporting "auto " as well would be easy. Supporting it in such a way
that it can be mixed freely with colors and attributes as in
%C(bold auto green) would be a bit harder. Could this lead to confusion
between the auto for terminal-detection and the one for automatic color
selection?
The documentation cited above says the color specification was explained
together with the color.branch.* config option, but that part only says
(from Documentation/config.txt):
color.branch.<slot>::
Use customized color for branch coloration. `<slot>` is one of
`current` (the current branch), `local` (a local branch),
`remote` (a remote-tracking branch in refs/remotes/),
`upstream` (upstream tracking branch), `plain` (other
refs).
It really is described earlier in the same file, in the Values section
(a fitting place, I think). Here's just the first sentence:
color::
The value for a variable that takes a color is a list of
colors (at most two, one for foreground and one for background)
and attributes (as many as you want), separated by spaces.
Patch below. Does it help a little?
> Also:
> Given it's very rare to want only part of a string to emit colour codes,
> if something like "bold" carries through until a "no-bold", why doesn't
> "auto" do the same thing?
No state is kept for "auto,". Attributes and colors are switched
separately by terminals, that's why e.g. bold stays in effect through
a color change -- unless you specify an attribute change as well.
Offering a way to enable terminal-detection for all color codes of a
format would be useful, but using the existing "auto," prefix for that
would be a behaviour change that could surprise users.
René
-- >8 --
Subject: [PATCH] pretty: fix document reference for color specification
Signed-off-by: Rene Scharfe <l.s.r@xxxxxx>
---
Documentation/pretty-formats.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index a942d57..89e3bc6 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -166,7 +166,8 @@ endif::git-rev-list[]
- '%Cgreen': switch color to green
- '%Cblue': switch color to blue
- '%Creset': reset color
-- '%C(...)': color specification, as described in color.branch.* config option;
+- '%C(...)': color specification, as described under Values, color in the
+ "CONFIGURATION FILE" section of linkgit:git-config[1];
adding `auto,` at the beginning will emit color only when colors are
enabled for log output (by `color.diff`, `color.ui`, or `--color`, and
respecting the `auto` settings of the former if we are going to a
--
2.10.1