Re: Difficulty with parsing colorized diff output

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Dec 11, 2018, 16:28 UTC
Message-ID: <871s6oni3a.fsf@evledraar.gmail.com>
In-Reply-To: <20181211101742.GE31588@sigill.intra.peff.net>

On Tue, Dec 11 2018, Jeff King wrote:

Show 18 quoted lines

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