bug#17522: diff-mode frustrates attempt to correct corrupted diff file.

[Alan Mackenzie]

Hello, Stefan.

On Wed, May 21, 2014 at 09:32:11PM -0400, Stefan Monnier wrote:
> >> Maybe not a bug, but a misfeature: the ",0" is probably because the first
> >> line after the @...@ is empty, which normally "can't" be part of a hunk,
> >> so this empty line is taken as an "end of hunk".
> > OK.  But patch appears to accept a blank line (in a unified diff)
> > without complaint.

> Indeed, "patch" at some point was changed so as to accept empty lines.
> diff-mode.el was partly changed to accommodate that looser format, but
> not 100% (and in the case of updating line counts while editing the
> patch, it's a bit more delicate since, contrary to "patch" we can't
> rely on the line counts to decide whether an empty line marks the end of
> a hunk or not).

Why not?  If you're going to carry on making surreptitious changes to
hunk headers, you'll need to determine the start and end of hunks
reliably, especially corrupted hunks.  This can't be done with 100%
certainty, and is going to involve heuristics.  A good way might be to
scan a hunk _forwards_ counting lines before the first change to that
hunk.  We know that, in broken unified patches, empty lines are liable to
have their single space removed, and long lines are liable to be split.

> >> If you add a space on that line, the count should be updated again and
> >> start looking more sane.
> > This is all besides the point.  I did not edit the hunk header,
> > therefore I don't expect it to be changed behind my back.  If I need
> > the header to be recalculated, surely there should be a command
> > for that.

> diff-mode tries to be fancier and do that transparently.  You're just
> bumping into a bug of that code (regardless of how the empty-line is
> handled, a line count of 0 for both sides of the hunk is clearly not
> right).

[ .... ]

> BTW, I remember writing some kind of "fix corrupted hunk" code.
> Oh, yes, it's in diff-sanity-check-hunk.  Can you try to see if it can
> auto-fix your corrupted patch?

The code for diff-sanity-check-hunk is unfinished.  It asks "Try to
auto-fix word wrap damage?", but does nothing when you say yes.  It also
doesn't check the line counts, at least, not for unified diffs.

> M-x diff-goto-source RET is probably the easiest way to trigger it
> (sadly, it's not provided as a separate command).

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).