Re: Difficulty with parsing colorized diff output
- From
Jeff King <peff@peff.net>
- Date
- Dec 11, 2018, 10:17 UTC
- Message-ID
- <20181211101742.GE31588@sigill.intra.peff.net>
- In-Reply-To
- <CAGZ79kbd=2_eHdbVYwmNoAYupwnP3YDn6nT0m=v1CL0AkWXk=Q@mail.gmail.com>
On Mon, Dec 10, 2018 at 07:26:46PM -0800, Stefan Beller wrote:
Show 7 quoted lines
> > Context lines do have both. It's just that the default color for context > > lines is empty. ;) > > The content itself can contain color codes. > > Instead of unconditionally resetting each line, we could parse each > content line to determine if we actually have to reset the colors.
Good point. I don't recall that being the motivation back when this behavior started, but it's a nice side effect (and the more recent line you mentioned in emit_line_0 certainly is doing it intentionally).
That doesn't cover _other_ terminal codes, which could also make for confusing output, but I do think color codes are somewhat special. We generally send patches through "less -R", which will pass through the colors but show escaped versions of other codes.
> Another idea would be to allow Git to output its output > as if it was run through test_decode_color, slightly related: > https://public-inbox.org/git/20180804015317.182683-8-sbeller@google.com/ > i.e. we'd markup the output instead of coloring it.
Yeah, I think in the most general form, the problem is that colorizing (including whitespace highlighting) loses information within a single line. It would be nice to have a machine-readable format that represents all the various annotations (like whitespace and coloring moved bits) that Git computes.
-Peff