bug#43297: 27.1; corrupts patch when diff-update-on-the-fly is set to nil

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> An easier way to reproduce this bug is to just load the example patch
> into a buffer and then eval-ing
>
>   (diff-fixup-modifs (point-min) (point-max))
>
> This shouldn't change the contents, but it does.

Poking around in the code shows that it is indeed the signature that
triggers the misbehaviour.  It goes to the end of the buffer and then
goes backward, line by line, and this is triggered:

              (pcase (char-after)
                (?\s (cl-incf space))
                (?+ (cl-incf plus))
                (?- (cl-incf minus))

Which makes it fix the line numbers in the hunk incorrectly.

I'm not familiar with this code at all -- it seems to be written with
the idea that there's just a patch in the current buffer, and nothing
else.  (At least at the end of the buffer.)  And here's it's a patch in
an email, so there's extra stuff.

I don't see any obvious ways of fixing this...  anybody got any ideas?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no