Re: [PATCH] Improve contrib/diff-highlight to highlight unevenly-sized hunks

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 19, 2015, 04:49 UTC
Message-ID: <xmqqmvzwb8vk.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20150619035408.GA23679@peff.net>

Jeff King <peff@peff.net> writes:

> ... I think you could also argue that
> because of whitespace-highlighting, colorized diffs are fundamentally
> going to have colors intermingled with the content and should not be
> parsed this way.

Painting of whitespace breakages is asymmetric [*1*]. If you change something on a badly indented line without fixing the indentation, e.g.

	-<SP><TAB>hello-world
        +<SP><TAB>hello-people

only the space-before-tab on the latter line is painted.

For the purpose of your diff highlighting, however, you would want to treat the leading "<SP><TAB>hello-" on preimage and postimage lines as unchanged.

Which means that you shouldn't be reading a colored output without ignoring the color-control sequences.

So I think you arrived at the correct conclusion.

> All the more reason to try to move this inside diff.c, I guess.

That too, probably.

If we were to do this, I think it may make sense to separate the logic to compute which span of the string need to be painted in what color and the routine to actually emit the colored output. That is, instead of letting ws-check-emit to decide which part should be in what color _and_ emitting the result, we should have a helper that reads <line, len>, and give us an array of spans to flag as whitespace violation. Then an optional diff-highlight code would scan the same <line, len> (or a collection of <line, len>) without getting confused by the whitespace errors and annotate the spans to be highlighted. After all that happens, the output routine would coalesce the spans and produce colored output.

Or something like that ;-)

[Footnote]

*1* We recently added a knob to allow us paint them on preimage and common lines, too, but that is not the default.