all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Alan Mackenzie <acm@muc.de>
Cc: 17522@debbugs.gnu.org
Subject: bug#17522: diff-mode frustrates attempt to correct corrupted diff file.
Date: Wed, 21 May 2014 21:32:11 -0400	[thread overview]
Message-ID: <jwva9aa8vah.fsf-monnier+emacsbugs@gnu.org> (raw)
In-Reply-To: <20140521215636.GA3908@acm.acm> (Alan Mackenzie's message of "Wed, 21 May 2014 21:56:36 +0000")

>> 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	other threads:[~2014-05-22  1:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-18 10:50 bug#17522: diff-mode frustrates attempt to correct corrupted diff file Alan Mackenzie
2014-05-19 15:39 ` Glenn Morris
2014-05-20 13:54 ` Stefan Monnier
2014-05-21 21:56   ` Alan Mackenzie
2014-05-22  1:32     ` Stefan Monnier [this message]
2014-05-22 21:14       ` Alan Mackenzie
2014-05-23  2:07         ` Stefan Monnier
2014-05-23 20:43           ` Alan Mackenzie
2014-05-24  3:19             ` Stefan Monnier
2014-05-25 16:07       ` Alan Mackenzie
2014-05-25 20:18         ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwva9aa8vah.fsf-monnier+emacsbugs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=17522@debbugs.gnu.org \
    --cc=acm@muc.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.