On Thu, Jun 23, 2016 at 11:52:51AM -0700, Junio C Hamano wrote: > >> It indeed is fun and it even makes sense in this context: > >> > >> $ ./git -c diff.color.old='red strike' show > > > > Ooh, I hadn't thought of that. It's a bit noisy for my tastes in a > > line-oriented diff, but with --color-words, it actually helps quite a > > bit (try it on the documentation patch from this series, for example). > > What I usually use is diff.color.old='red reverse' because I cannot > easily tell between black and dark red in small font on my white > background. s/reverse/strike/ makes it much less noisy. You may find "bold red" a little easier, as it often uses a brighter variant. We also support 8-bit and 24-bit color these days. So you can probably do something like diff.color.old='#ff0000'. That's all old, though, so I imagine you might have played with it long ago. I have a black background myself, and save "reverse" for diff-highlight. > What is sad for me is that I usually work in GNU screen, displaying on > either xterm or gnome-terminal. Without screen, strike shows but > inside it I cannot seem to be able to get strike-thru in effect. Hmm. I see the same thing screen and with tmux, as well (though I don't usually use either myself). I suspect they have to filter ANSI codes because they're using the codes themselves (so anything that moves the cursor is going to be a definite problem), and strike-through probably just isn't common enough to have been added to the whitelist. It does work with dtach, but that is probably because that program only does the remote-socket parts of screen/tmux, and so wouldn't need any filtering at all. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html