GNU bug report logs - #17522
diff-mode frustrates attempt to correct corrupted diff file.

Previous Next

Full log

Message #14 received at 17522 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 17522 <at> debbugs.gnu.org
Subject: Re: bug#17522: diff-mode frustrates attempt to correct corrupted
 diff file.
Date: Wed, 21 May 2014 21:56:36 +0000

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.