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

Previous Next

Full log

Message #16 received at 43297 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Mark H Weaver <mhw <at> netris.org>, 43297 <at> debbugs.gnu.org
Subject: Re: bug#43297: 27.1; corrupts patch when diff-update-on-the-fly is
 set to nil
Date: Fri, 16 Oct 2020 10:29:14 +0200

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

    Lars> Lars Ingebrigtsen <larsi <at> 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
-- 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.