Re: [PATCH v2 7/7] color: support strike-through attribute

From: Jeff King <peff@peff.net>
Date: Jun 23, 2016, 19:04 UTC
Message-ID: <20160623190414.GA568@sigill.intra.peff.net>
In-Reply-To: <xmqqlh1vivp8.fsf@gitster.mtv.corp.google.com>

On Thu, Jun 23, 2016 at 11:52:51AM -0700, Junio C Hamano wrote:

Show 11 quoted lines

> >> 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