From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#34720: 26.1; Reverting a GPG buffer moves all markers to the end of the file Date: Tue, 27 Aug 2019 11:00:09 +0300 Message-ID: <83mufvdomu.fsf@gnu.org> References: <87a7ic9due.fsf@gnu.org> <87muhnrwvs.fsf@mouse.gnus.org> <875zmk5r5u.fsf@gnus.org> <83sgpofjc9.fsf@gnu.org> <87k1b04a3x.fsf@gnus.org> <83pnksfel0.fsf@gnu.org> <87v9uj2i7l.fsf@gnus.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="54782"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 34720@debbugs.gnu.org, dunni@gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Aug 27 10:01:16 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i2WPk-000Dy2-Om for geb-bug-gnu-emacs@m.gmane.org; Tue, 27 Aug 2019 10:01:16 +0200 Original-Received: from localhost ([::1]:47824 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2WPh-00037h-TX for geb-bug-gnu-emacs@m.gmane.org; Tue, 27 Aug 2019 04:01:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33046) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2WPb-00037b-4w for bug-gnu-emacs@gnu.org; Tue, 27 Aug 2019 04:01:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i2WPW-0006sc-1W for bug-gnu-emacs@gnu.org; Tue, 27 Aug 2019 04:01:07 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38802) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i2WPV-0006sY-UM for bug-gnu-emacs@gnu.org; Tue, 27 Aug 2019 04:01:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1i2WPV-0006DD-Oj for bug-gnu-emacs@gnu.org; Tue, 27 Aug 2019 04:01:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 27 Aug 2019 08:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34720 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 34720-submit@debbugs.gnu.org id=B34720.156689281721079 (code B ref 34720); Tue, 27 Aug 2019 08:01:01 +0000 Original-Received: (at 34720) by debbugs.gnu.org; 27 Aug 2019 08:00:17 +0000 Original-Received: from localhost ([127.0.0.1]:47623 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i2WOm-0005TP-9J for submit@debbugs.gnu.org; Tue, 27 Aug 2019 04:00:16 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:52690) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i2WOk-0005L9-Gp for 34720@debbugs.gnu.org; Tue, 27 Aug 2019 04:00:14 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54165) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i2WOf-0006U1-7r; Tue, 27 Aug 2019 04:00:09 -0400 Original-Received: from [176.228.60.248] (port=1595 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i2WOd-0002Nx-IH; Tue, 27 Aug 2019 04:00:08 -0400 In-reply-to: <87v9uj2i7l.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 27 Aug 2019 09:14:22 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:165945 Archived-At: > From: Lars Ingebrigtsen > Cc: dunni@gnu.org, 34720@debbugs.gnu.org > Date: Tue, 27 Aug 2019 09:14:22 +0200 > > Eli Zaretskii 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); These just restore a single marker: the point marker. That's a far cry from restoring all the markers. I don't think the latter is possible in all cases without violating the principle of least astonishment (by placing the markers at locations that have nothing in comm on with where they have been before the editing operation). > 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. That's because markers can only be preserved by operations on the C level. If the C-level handling cannot preserve a marker, then it is unsafe, to say the least, to try to second-guess that by moving the markers manually from Lisp. Specifically, if the editing operation deletes the text on both sides of a marker, there's no reasonable place, in general, to have this marker after some other text is inserted. You may think otherwise if the inserted text happens to be very similar to the one which was deleted, but that's an illusion. If some Lisp program wants to preserve markers during editing, then it must call the likes of replace-buffer-contents to do the job. > 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. That has come up before. Giving Lisp programs direct access to markers is dangerous, because Emacs uses markers internally for various bookkeeping purposes, such as conversion between character and byte positions. But maybe I misunderstand what you want to do, because you didn't answer my question about restoring markers after replacement. > >> 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. It's a rather niche capability, so I'm not surprised it doesn't yet have a lot of users.