Re: Patch text in git-add patch mode lacks whitespace highlighting

> Jeff King <peff@peff.net> writes:
> 
> > If just the human-readable one, then many options that change the line
> > count would be problems: diff.context, diff.interhunkcontext,
> > diff.orderfile, etc.
> >
> > If both, then some options would be problematic for applying. Just
> > looking over the list, these jump out at me:
> >
> >   - color.diff=always would obviously be an issue (though TBH I think
> >     anybody doing that is inviting a lot of breakages anyway)
> >
> >   - diff.external would be a problem if it kicked in, though I think it
> >     would require --ext-diff to actually do anything
> >
> >   - diff.submodule would generate diffs that can't be applied
> 
> What can truly help "git add -p" might be a new output mode from
> "git diff", perhaps, in which instead of writing a stream of text
> (with color codes intermixed), the output machinery makes a call to
> API-user supplied callbacks to report ("type of output line", "the
> payload", "list of coloring information") tuples for each line, so
> that the API-user can synthesize _both_ versions it currently uses
> with a single invocation of "diff"?  There may be tons of "output
> line" types, like the diff header, hunk header, context, removed,
> added, etc., and depending on the type, the form the payload takes
> may be different (e.g. a context line may be just a plain text, a
> hunk header line may be a five-tuple (pre- and post-context line
> numbers and line countsm plus the function-header line text).