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

[Robert Pluim]

>>>>> On Fri, 16 Oct 2020 09:01:54 +0200, Lars Ingebrigtsen <larsi@gnus.org> 
>>>>> said:

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

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

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

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

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

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

Search backwards from end-of-buffer for "-- " and then narrow the
buffer from (point-min) to there? Kind of hacky I guess, but otherwise
you'll have to complicate the pcase.

Robert
--