Jeff King <peff@xxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html