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

Previous Next

Package: emacs;

Reported by: Ian Dunn <dunni <at> gnu.org>

Date: Sun, 3 Mar 2019 15:29:01 UTC

Severity: normal

Tags: confirmed, fixed

Found in version 26.1

Fixed in version 27.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34720 <at> debbugs.gnu.org, dunni <at> gnu.org
Subject: bug#34720: 26.1; Reverting a GPG buffer moves all markers to the end of the file
Date: Tue, 27 Aug 2019 09:14:22 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

> IOW, there's no guarantee that markers will be preserved across
> operations that replace text.

No, but we have a small handful of functions that do best effort...  but
they're deep in the C code and not accessible.

Finsert_file_contents has this:

  /* Replacement should preserve point as it preserves markers.  */
  if (!NILP (replace))
    {
      window_markers = get_window_points_and_markers ();
      record_unwind_protect (restore_point_unwind,
			     XCAR (XCAR (window_markers)));
    }
    ...
 handled:

  if (inserted > 0)
    restore_window_points (window_markers, inserted,
			   BYTE_TO_CHAR (same_at_start),
			   same_at_end_charpos);

The problem that this bug report addresses is that Lisp level functions
that implement special handlers for insert-file-contents (in this case,
epa-file-insert-file-contents) doesn't have access to the internals
necessary to give the user the same experience that the built-in version
gives the user.

My suggestion is basically to make DEFUN shims over
get_window_points_and_markers/restore_window_points, and create a new
macro `with-saved-markers' that would use that pair to do this cheap,
best-effort thing that Finsert_file_contents does.

> But I'm not opposed to adding support for string as the source for
> replacement.  Just be aware that the code which access such a string
> must be highly optimized, because it is executed in the innermost loop
> of the code.

I just had a peek at the code, and it indeed highly optimised...

>> No wonder this function has gotten one single usage after it was
>> introduced two years ago.  (Well, one usage to
>> replace-region-contents, which then calls the function.)  (Unless
>> I'm grepping wrong.)
>
> replace-region-contents is used in json.el.

Yes, that's the one single usage of this machinery.

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




This bug report was last modified 5 years and 261 days ago.

Previous Next


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