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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 17522 <at> debbugs.gnu.org
Subject: bug#17522: diff-mode frustrates attempt to correct corrupted diff file.
Date: Wed, 21 May 2014 21:32:11 -0400

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

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

> Why do people hand edit patches anyway?

All kinds of reasons.  The case of corrupted patches was definitely not
the main motivation for the line-count-update feature (after all, for
corrupted patches, you don't want to mess with the line counts).

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

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

It can be easier to take a hunk and edit it to remove some of the
changes it performs, then it is to change the source code to then
re-generate a new hunk.


        Stefan

Previous Next

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