Re: [PATCH v2 13/18] color: provide inverted colors, too
- From
Jeff King <peff@peff.net>
- Date
- May 7, 2018, 07:37 UTC
- Message-ID
- <20180507073736.GA31170@sigill.intra.peff.net>
- In-Reply-To
- <nycvar.QRO.7.76.6.1805062119051.77@tvgsbejvaqbjf.bet>
On Sun, May 06, 2018 at 09:20:46PM -0400, Johannes Schindelin wrote:
Show 22 quoted lines
> > Heh, of course you knew that already, as I just noticed your patch is > > using the reverse attribute internally (I had thought at first glance > > you were just specifying the background independently). > > > > So really, I guess all I am arguing for is having GIT_COLOR_INV (or > > REVERSE) as a constant, and then teaching the code to combine it with > > the existing "new" color. It's perfectly OK to have: > > > > \x1b[7m\x1b[36m > > > > instead of: > > > > \x1b[7;36m > > > > It's two extra bytes, but I doubt anybody cares. > > Yep, I agree that it is a small price to pay for the benefit of simply > using the reverse of diff.color.old (and .new). > > While at it, I also changed the hunk header colors: they are *also* simply > the same ones, with the outer one having background and foreground > reversed.
That sound sane.
If we ever did want to care about the number of bytes we output, I suspect we could "compress" our ANSI terminal outputs by collapsing adjacent colors into a single one. But IMHO it's not even worth worrying about that optimization at this point.
-Peff