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: Mon, 26 Aug 2019 12:42:03 +0300 Message-ID: <83pnksfel0.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> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="171872"; 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 Mon Aug 26 11:43:12 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 1i2BWq-000ibY-JQ for geb-bug-gnu-emacs@m.gmane.org; Mon, 26 Aug 2019 11:43:12 +0200 Original-Received: from localhost ([::1]:51286 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2BWp-00066z-HK for geb-bug-gnu-emacs@m.gmane.org; Mon, 26 Aug 2019 05:43:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58957) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2BWh-00066e-H7 for bug-gnu-emacs@gnu.org; Mon, 26 Aug 2019 05:43:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i2BWg-0008Ah-BP for bug-gnu-emacs@gnu.org; Mon, 26 Aug 2019 05:43:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36792) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i2BWg-0008AY-7x for bug-gnu-emacs@gnu.org; Mon, 26 Aug 2019 05:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1i2BWg-0006CL-4V for bug-gnu-emacs@gnu.org; Mon, 26 Aug 2019 05:43:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 26 Aug 2019 09:43:02 +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.156681253123721 (code B ref 34720); Mon, 26 Aug 2019 09:43:02 +0000 Original-Received: (at 34720) by debbugs.gnu.org; 26 Aug 2019 09:42:11 +0000 Original-Received: from localhost ([127.0.0.1]:45613 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i2BVq-0006AX-Jt for submit@debbugs.gnu.org; Mon, 26 Aug 2019 05:42:10 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:50338) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i2BVo-0006AE-T8 for 34720@debbugs.gnu.org; Mon, 26 Aug 2019 05:42:09 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36915) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i2BVj-0007dl-L6; Mon, 26 Aug 2019 05:42:03 -0400 Original-Received: from [176.228.60.248] (port=2961 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i2BVi-0008Tx-LD; Mon, 26 Aug 2019 05:42:03 -0400 In-reply-to: <87k1b04a3x.fsf@gnus.org> (message from Lars Ingebrigtsen on Mon, 26 Aug 2019 10:14:10 +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:165895 Archived-At: > From: Lars Ingebrigtsen > Cc: dunni@gnu.org, 34720@debbugs.gnu.org > Date: Mon, 26 Aug 2019 10:14:10 +0200 > > Eli Zaretskii writes: > > > Markers cannot be preserved in every situation, there's no way around > > this basic fact. > > No, but commands like `revert-buffer' (via insert-file-contents) try to > keep most of them around. "As much as possible". In some situation, it's impossible, at least for some of the markers. That happens when the text where markers pointed to is entirely replaced. IOW, there's no guarantee that markers will be preserved across operations that replace text. > > replace-buffer-contents is a primitive, so it can legitimately rely on > > Lisp programs to set up whatever preconditions it needs for it to > > work. It MUST have a buffer to work with; if you want to replace with > > a string, insert that string into a buffer and call the primitive. > > Why is that a problem? > > Why MUST it have a buffer to get the input data from? Because no one has written code to support a string, I guess. Feel free to work on that if you think it's important enough. > You get a text from somewhere, and it often ends up in a string (as in > the epa case). If you want to safely feed that to this function, you > have to say something along the lines of > > (let ((buffer (current-buffer))) > (with-temp-buffer > (insert string) > (let ((temp (current-buffer))) > (with-current-buffer buffer > (replace-buffer-contents temp))))) > > which is horrible, horrible, and horrible. I see nothing horrible here. More importantly, I suspect the string actually started in some buffer, in which case all of the complications above could be avoided. (I generally consider code in Emacs that manipulates large text strings to be broken by design.) 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. > 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. As for the users of replace-buffer-contents, I could think of several alternative reasons for its rare usage: . the function is relatively new, and was horribly slow before Emacs 27 . the use cases for it are relatively rare, otherwise we'd have it long ago > >> Would anybody mind if I just write a `with-saved-markers' macro in > >> subr-x, which would make all these problems to away and make the > >> solution a two-liner in epa itself? > > > > What would that macro do, exactly? > > Gather the markers, execute the body, and then put the markers back > where they were. How do you "put the markers back where they were"? That's the crucial point, and I don't see how would you pull that out when the text is significantly modified.