On Mon, Dec 10, 2018 at 07:26:46PM -0800, Stefan Beller wrote: > > 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@xxxxxxxxxx/ > 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
