Subject: Re: bug#34720: 26.1; Reverting a GPG buffer moves all markers to the end of the file

From: Lars Ingebrigtsen <[email-masked]>
Date: Tue, 27 Aug 2019 10:37:40 +0200

Continuing to read the code in the massive Finsert_file_contents, even
with a way to get and restore the markers, replicating all that it does
seems like a rather hair-raising task.  For instance:

  /* If requested, replace the accessible part of the buffer
     with the file contents.  Avoid replacing text at the
     beginning or end of the buffer that matches the file contents;
     that preserves markers pointing to the unchanged parts.

     Here we implement this feature in an optimized way
     for the case where code conversion is NOT needed.
     The following if-statement handles the case of conversion
     in a less optimal way.

     If the code conversion is "automatic" then we try using this
     method and hope for the best.
     But if we discover the need for conversion, we give up on this method
     and let the following if-statement handle the replace job.  */

Oh:

/* FIXME: insert-file-contents should be split with the top-level moved to
   Elisp and only the core kept in C.  */

Right.

Hm...  Now what's this?

  /* If the file name has special constructs in it,
     call the corresponding file name handler.  */
  handler = Ffind_file_name_handler (filename, Qinsert_file_contents);
  if (!NILP (handler))
    {
      val = call6 (handler, Qinsert_file_contents, filename,
		   visit, beg, end, replace);
      if (CONSP (val) && CONSP (XCDR (val))
	  && RANGED_FIXNUMP (0, XCAR (XCDR (val)), ZV - PT))
	inserted = XFIXNUM (XCAR (XCDR (val)));
      goto handled;
    }

That's the code that calls out to `epa-file-insert-file-contents', isn't
it?  Hm, yes it is.  And handled: will restore the markers if inserted
is larger than zero.

But it seems to be larger than zero, so I think I need to do more
debugging.

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