[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