On Wed, May 31, 2017 at 11:33:31AM -0700, Irving Rabin wrote:
> Specifically, if the field is supposed to be white, it doesn't mean it
> should be literally 0xFFFFFF. It should be the color that I have
> configured as White color for my console emulator.
>
> I like light-screen terminals, and I configure my ANSI colors in the
> way that they are clearly visible on the background and clearly
> distinct between themselves. In my terminal settings background is
> light-yellow, Black is black, Yellow is brown, Red is dark red,
> Magenta is purple and White is dark gray. I set it once and I can use
> it everywhere - all Unix commands work correctly, I can edit
> highlighted source code in Vim, and all my color settings are
> respected.
Git outputs ANSI color codes, which are interpreted by your terminal.
You _can_ configure Git to send 24-bit color codes if your terminal
supports it, but by default it uses the traditional set of limited color
and attribute codes.
What does running the following snippet in your shell look like?
-- >8 --
while read name code; do
printf '\033[%sm%s\033[m\n' "$code" "$name"
done <<-\EOF
normal
bold 1
red 31
green 32
yellow 33
blue 34
magenta 35
cyan 36
bold-red 1;31
bold-green 1;32
bold-yellow 1;33
bold-blue 1;34
bold-magenta 1;35
bold-cyan 1;36
EOF
-- 8< --
If any of the colors are not what you expect, is there a pattern? E.g.,
I wouldn't be surprised if "bold" shows up as bright white. In many
modern terminal emulators, the bold variants need to be configured
separately from the non-bold ones, and default to lighter variants of
their non-bold counterparts. The solution there would be to check your
terminal emulator config.
If it does all look as you'd expect, try adding "| less -R" to the end of
the "done <<-\EOF" line. Most of Git's output goes through that pager
(though I _think_ it's mostly just passing through the ANSI codes, so it
wouldn't have any effect).
-Peff
