Re: diff-mode misinterprets empty lines.

[Jim Meyering <jim@meyering.net>]

David Kastrup <dak@gnu.org> wrote:

> Jim Meyering <jim@meyering.net> writes:
>
>> Since I was thinking of using that new option always, I considered
>> changing the source to make the default in my private binary be to
>> enable the new option.  Since I'd rather not have to make private
>> changes, what do you think about having a compile-time option to
>> change the default?  Not even a configure-time flag.
>>
>> Since Emacs may eventually change to accept the new format, it may
>> make sense to change the default and to provide a
>> --no-suppress-blank-empty option.
>
> No, it does not make sense to change the default.  Emacs is just one of
> many tools processing diff output.  I remember gratuitous breakage of
> git, too.  There are far too many tools relying on the _documented_ diff
> output formats (please read
> (info "(diff) Context")

Hi David,

My sole interest is in the change to the *unidiff* format.
And that was not documented, back then.

> for a detailed explanation of the diff formats) that it makes sense
> breaking things all around for no tangible benefit.

The benefit was tangible enough to me to propose the change, and to Paul
to allow and extend it.  I'm sure you know that git tools have been
accepting the trailing-blank-free format for over a year, so they too
saw some benefit in accepting the new format.

Too many tools these days can automatically remove trailing blanks.
If I keep my code free of trailing blanks (and I do), those tools should
have no affect on my code.  I want the same benefit for diffs of my code.
IMHO, it's an improvement at least to allow a trailing-blank-free diff format.

> I don't understand why this change was made in the first place, and I
> don't understand why people would want to gratuitously make the format
> less reliable to parse by tools, when the main usage _is_ the
> application by independent tools.

You seem to underestimate Paul's concern for portability.  Git was young
at the time, and the format they cared about was unidiff, so it wasn't
*that* big a deal to fix it.  If we had known about the incompatibility
with diff-mode back then, I'm sure the new behavior would never have
been made the default.