Re: %C(auto) not working as expected
- From
René Scharfe <l.s.r@web.de>
- Date
- Oct 9, 2016, 13:24 UTC
- Message-ID
- <25c17e16-2456-7da3-ae22-2dc812a3aa0d@web.de>
- In-Reply-To
- <65d8def3-df62-6c45-7d8f-79b6a8769bf5@hale.ee>
Am 09.10.2016 um 12:04 schrieb Tom Hale:
Show 6 quoted lines
> 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.
Show 5 quoted lines
> 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@web.de> --- 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