bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Monnier
Subject: bug#17522: diff-mode frustrates attempt to correct corrupted diff file.
Date: Wed, 21 May 2014 21:32:11 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]