[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11894: 24.1.50; [PATCH] diff-apply-hunk can be off by 1 line when th
bug#11894: 24.1.50; [PATCH] diff-apply-hunk can be off by 1 line when the hunk is 0-context pure removal
Wed, 18 Jul 2012 08:53:15 -0400
Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)
> Not sure if we can rely on the line number being always off by 1 in such
> hunks (there's no insertion, so, technically, the second line number in the
> header could be arbitrary), but at least 3 versions of diff across
> 2 different OSes work the same in this regard.
This looks like a bug in those versions of diff (not that I know
a non-buggy version, tho). Could you report it to GNU diffutils.
> Note that if you try to create such hunk with `diff-split-hunk' (by slicing
> it off a bigger hunk), the line number won't be off by 1.
Oh, right, so there is a "version of diff" that doesn't have this bug ;-)
> Maybe that's a bug in `diff-split-hunk'.
I doubt it. At least `patch' seems to agree with diff-mode.el:
% diff -c0 footest1 footest2 |patch -o footest3 footest1
patching file footest1
patch: **** replacement text or line numbers mangled in hunk at line 8
> - (goto-char (point-min)) (forward-line (1- (string-to-number line)))
> + (let ((line-num (string-to-number line)))
> + ;; When the hunk is pure deletion, line number is off by 1.
> + (when (string= (if reverse (car old) (car new)) "")
> + (incf line-num))
> + (goto-char (point-min)) (forward-line (1- line-num)))
Context/unified diffs with 0 context are pretty rare, so I'd rather not
work around such a bug if I don't really have to.