GNU bug report logs -
#17522
diff-mode frustrates attempt to correct corrupted diff file.
Previous Next
Full log
Message #32 received at 17522 <at> debbugs.gnu.org (full text, mbox):
Hello, Stefan.
On Wed, May 21, 2014 at 09:32:11PM -0400, Stefan Monnier wrote:
> >> 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).
Why not? If you're going to carry on making surreptitious changes to
hunk headers, you'll need to determine the start and end of hunks
reliably, especially corrupted hunks. This can't be done with 100%
certainty, and is going to involve heuristics. A good way might be to
scan a hunk _forwards_ counting lines before the first change to that
hunk. We know that, in broken unified patches, empty lines are liable to
have their single space removed, and long lines are liable to be split.
> >> 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).
[ .... ]
> 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?
The code for diff-sanity-check-hunk is unfinished. It asks "Try to
auto-fix word wrap damage?", but does nothing when you say yes. It also
doesn't check the line counts, at least, not for unified diffs.
> M-x diff-goto-source RET is probably the easiest way to trigger it
> (sadly, it's not provided as a separate command).
> Stefan
--
Alan Mackenzie (Nuremberg, Germany).
This bug report was last modified 11 years and 21 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.