bug#11894: 24.1.50; [PATCH] diff-apply-hunk can be off by 1 line when the hunk is 0-context pure removal

[Dmitry Gutov]

On 18.07.2012 16:53, Stefan Monnier wrote:
> > 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.

As per Andreas' comment, this is probably not a bug.

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

Yep, and I'll use it as a workaround if this bug won't be fixed.

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

`info diff` says: "For proper operation, `patch' typically needs at 
least two lines of context.", so this just may be a documented problem 
nobody cares about.

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

I'm fine either way, just wanted to report this.

--Dmitry