emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: diff-mode misinterprets empty lines.


From: David Kastrup
Subject: Re: diff-mode misinterprets empty lines.
Date: Wed, 05 Dec 2007 15:59:11 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux)

Jim Meyering <address@hidden> writes:

> David Kastrup <address@hidden> wrote:
>
>> 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")
>
> My sole interest is in the change to the *unidiff* format.
> And that was not documented, back then.

Huh?  What makes you say that?

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

Huh?  What tangible benefit is "does not break in newer versions but
only gets less reliable"?

> Too many tools these days can automatically remove trailing blanks.

Why would you apply them to a _diff_?

> If I keep my code free of trailing blanks (and I do), those tools
> should have no affect on my code.

But your code is written as _diffs_.  diffs are _output_ formats, not
input formats.

> I want the same benefit for diffs of my code.

What benefit?

> IMHO, it's an improvement at least to allow a trailing-blank-free diff
> format.

We are not talking about whether it makes sense for Emacs diff to be
able to work around the output of broken file transfers.  We are talking
about whether it makes sense to break the output in the first place.
And a "trailing-blank-free diff format" gained in this manner is an
illusion, anyway, since diff must be able to represent lines differing
in trailing space.

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

Huh?  How does one gain portability by breaking output formats?

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

Huh?  What do you mean by "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.

We are not talking about an "incompatibility with diff-mode".  We are
talking about breaking the format specification.  That concerns _any_
tool reading the output of diff, not just diff-mode.

So again: where is the tangible benefit of breaking diff output in the
first place?  Because broken communication channels might break it, too?
What kind of benefit is it to prebreak it?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

[Prev in Thread] Current Thread [Next in Thread]