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

From: Alan Mackenzie <[email-masked]>
Date: Thu, 22 May 2014 21:14:07 +0000

Hi, Stefan.

On Wed, May 21, 2014 at 09:32:11PM -0400, Stefan Monnier wrote:
> >> 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.

Yes, but it sometimes fails, and then this "transparently" becomes a
euphemism for "fouls it up in a manner causing the user the maximum
difficulty in seeing what has happened".

At this point you snipped the main point of my last post, which was
this:

> > At the very least, surely Diff Mode should _ask_ me before splatting
> > my file.  Or at the very, very least even _inform_ me that it has
> > done so, rather than leaving it up to patch to issue its bewildering
> > error message.

So why can't we have a `y-or-n-p' or a `message' when diff-mode is about
to change a hunk header, possibly fouling it up?  It is the "fanciness"
and "transparency" which caused me so much grief, the not realising that
the hunk header had been automatically changed.  It never occurred to me
that Diff Mode might do something like this (except for a dim memory
that something like this happened to me once before).

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

Yes, but a line count of 1 for both sides, which might have happened if
the blank line was the second line in the hunk rather than the first,
would be equally 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?

It's getting late.  I'll have a look at this some time soon.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).