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

[Alan Mackenzie <acm@muc.de>]

Hi, Stefan.

On Tue, May 20, 2014 at 09:54:02AM -0400, Stefan Monnier wrote:
> >     @@ -3155,0 +3160,0 @

> > .  This is surely a bug.  The workaround seems to be to use Fundamental
> > Mode.

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

> 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.
(There is, but it doesn't have a key binding.)  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.

Why do people hand edit patches anyway?  Clearly, because patches
sometimes get corrupted, e.g. by email software, as happened to me.  For
this case, it doesn't make sense to recalculate the header.  But for
other reasons?  Why would anybody edit a patch hunk other than to repair
it?  It's not something I can imagine myself wanting to do.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).