I spent a morning wrestling with git after writing a minor GIMP fix
that I wanted to check in.
Deceptively simple ideas, like "Check the git log to see the expected
format of check-in messages", turned out to be easier said than done.
Part of the problem was git's default colors: colors calculated to be
invisible to anyone using a terminal with dark text on a light background.
And that sent me down the perilous path of git configuration.
git-config
does have a manual page. But it lacks detail: you can't get
from there to knowing what to change so that the first line of commits
in git log doesn't show up yellow.
But that's okay, thought I: all I need to do is list the default
settings, then change anything that's a light color like yellow to
a darker color. Easy, right?
Well, no. It turns out there's no way to get the default settings --
because they aren't part of git's config; they're hardwired into the
C code.
But you can find most of them with a
seach
for GIT_COLOR in the source.
The most useful lines are these the ones in diff.c, builtin-branch.c and
wt-status.c.
gitconfig
The next step is to translate those C lines to git preferences,
something you can put in a .gitconfig.
Here's a list of all the colors mentioned in the man page,
and their default values -- I used "normal" for grep and
interactive where I wasn't sure of the defaults.
[color "diff"]
plain = normal
meta = bold
frag = cyan
old = red
new = green
commit = yellow
whitespace = normal red
[color "branch"]
current = green
local = normal
remote = red
plain = normal
[color "status"]
header = normal
added = red
updated = green
changed = red
untracked = red
nobranch = red
[color "grep"]
match = normal
[color "interactive"]
prompt = normal
header = normal
help = normal
error = normal
The syntax and colors are fairly clearly explained in the manual:
allowable colors are normal, black, red, green,
yellow, blue, magenta, cyan and white. After the foreground color,
you can optionally list a background color. You can also list an
attribute, chosen from bold, dim, ul, blink and reverse --
only one at a time, no combining of attributes.
So if you really wanted to, you could say something like
[color "status"]
header = normal blink
added = magenta yellow
updated = green reverse
changed = red bold
untracked = blue white
nobranch = red white bold
Minimal changes for light backgrounds
What's the minimum you need to get everything readable?
On the light grey background I use, I needed to change the yellow, cyan
and green entries:
[color "diff"]
frag = cyan
new = green
commit = yellow
[color "branch"]
current = green
[color "status"]
updated = green
Disclaimer: I haven't tested all these settings -- because I haven't
yet figured out where all of them apply. That's another area where the
manual is a bit short on detail ...
Tags: git, programming, color
[
22:26 Feb 02, 2010
More programming |
permalink to this entry
]
I use a light background for my X terminals (xterm and rxvt):
not white, but a light grey that I find easy on the eyes.
Long ago, I spent the time to set up a custom vim color scheme
that works with the light background.
But sometimes I need to
run vim somewhere where I don't have access to my custom scheme.
It always starts up with a lot of the words displayed in
yellow, completely unreadable against a light background.
:set background=light
doesn't help -- the default colorscheme is already intended for a
light background, yet it still uses yellow characters.
I tried all the colorschemes installed with ubuntu's vim
(you can get a list of them with ls /usr/share/vim/vim71/colors).
The only light-background vim schemes that don't use yellow
all have their primary text color as red. Do a lot of people
really want to edit red text? Maybe the same people who think that
yellow is a dark color?
Curiously, it turns out that if you use one of these light
color schemes on a Linux console (with its black background),
the yellow text isn't yellow (which would show up fine against
black), but orange (which would be better on a light background).
Mikael knew the answer:
:set t_Co=88
This tells vim to use 88-color mode instead of its default of 8,
and the yellow text turns light blue. Not terrifically readable
but much better than yellow. Or, instead, try
:set t_Co=256
and the yellow/light blue text turns an ugly, but readable, orange
(probably the same orange as the console used).
So, vim users with dark-on-light terminal schemes: add
set t_Co=256 in your .vimrc (no colon)
and you'll be much happier.
Update: Pádraig Brady has a great page explaining more about
terminal
colour highlights, including a TERM=xterm-256color
setting to get
vim to use 256 colors automatically. There's also a lot of good advice
there on enabling colors in other console apps.
The only catch: on Ubuntu you do have to install the
ncurses-term package, which will get you xterm-256color as
well as 256color variants for lots of other terminal types.
Here's useful page on 256-Color
XTerms in Ubuntu.
Tags: editors, vim, color, tips
[
21:29 Mar 22, 2009
More linux/editors |
permalink to this entry
]
An upgrade from woody to sarge introduced a new problem with editing
mail messages in vim: Subject lines appeared in yellow, against my
light grey background, so they weren't readable any more.
Vim color files have always been a mystery to me. I have one which
I adapted from one of the standard color schemes, but I've never
been clear what the legal identifiers are or how to find out.
But I changed both places where it said "ctermfg=Yellow" to another
color, and nothing changed, so this time I had to find out.
Fortunately a nice person on #vim suggested :he synID (he
is short for "help", of course) which told me all I needed to know.
Put the cursor on the errant line and type:
:echo synIDattr(synID(line("."), col("."), 1), "name")
That told me that the Subject line was syntax class "mailSubject".
So I tried (copying other lines in my color file) adding this line:
hi mailSubject term=underline ctermfg=Red guifg=Red
and now all is happy again in vim land. I wish I'd learned that
synID trick a long time ago!
Tags: vim, color, editors, tips
[
09:59 Jun 22, 2005
More linux/editors |
permalink to this entry
]