GNU bug report logs - #34720
26.1; Reverting a GPG buffer moves all markers to the end of the file

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 34720 <at> debbugs.gnu.org, dunni <at> gnu.org
Subject: Re: bug#34720: 26.1; Reverting a GPG buffer moves all markers to
 the end of the file
Date: Fri, 30 Aug 2019 15:19:51 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 34720 <at> debbugs.gnu.org,  dunni <at> gnu.org
> Date: Fri, 30 Aug 2019 11:48:07 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> So the fix here is to make epa follow the same logic, perhaps?  That is,
> >> first get the text we're supposed to insert, then compare with the data
> >> in the buffer, and only start replacing at the point where we find the
> >> first difference?
> >
> > You want to replace the insert-file-contents with custom-tailored Lisp
> > code?  Even if possible and efficient enough, this would be a
> > specialized solution for only a single use case.  Right?  Other use
> > cases, with other insert-file-contents handlers, will each one have to
> > have their separate custom solutions, right?  All that just to keep
> > markers intact?
> 
> It's a problem common to all the insert-file-content handlers, I think?
> Now that I understand what the problem is (i.e., "don't replace the text
> at the start of the buffer with identical text"), I think fixing this in
> the epa case should hopefully be easy enough, and perhaps something more
> general can be extracted from that solution.  Which I have not written
> yet, so we'll see.  :-)

The problem is that getting at the new text to compare with is
specific to each handler, and some of them cannot be rewound (i.e.,
you cannot examine the same text more than once).

Previous Next

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