I just noticed that while `wsErrorHighlight = none` fixes the problem of extra green codes for regular diff, it fails to have any effect during interactive `git add -p`. > On 2018-12-11, at 11:41 AM, George King <george.w.king@xxxxxxxxx> wrote: > > I first started playing around with terminal colors about 5 years ago, and I recall learning the hard way that Apple Terminal at least behaves very strangely when you have background colors cross line boundaries: background colors disappeared when I scrolled lines back into view. I filed a bug thinking it couldn't be right and Apple closed it as behaving according to compatibility expectations. I never figured out whether they had misunderstood my report or if old terminals were just that crazy. Instead I decided that the safe thing to do was reset after every line. Perhaps some git author reached the same conclusion. > > From the perspective of parsing this output, it is really much easier if each line can be understood without considering state of previous lines. If anything, I think it is a safe approach to ensuring that it renders correctly on various terminals as well. > >> On 2018-12-11, at 11:28 AM, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: >> >> >> On Tue, Dec 11 2018, Jeff King wrote: >> >>> 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. >> >> I wonder if optimizing this one way or the other matters for some >> terminals. I.e. if we print out some huge diff of thousands of >> consecutive "green" added lines is it faster/slower on some of them to >> do one "begin green" and "reset" at the end, or is one line at a time >> better, or doesn't it matter at all? >
