From unknown Sun Jun 15 08:23:43 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#34720 <34720@debbugs.gnu.org> To: bug#34720 <34720@debbugs.gnu.org> Subject: Status: 26.1; Reverting a GPG buffer moves all markers to the end of the file Reply-To: bug#34720 <34720@debbugs.gnu.org> Date: Sun, 15 Jun 2025 15:23:43 +0000 retitle 34720 26.1; Reverting a GPG buffer moves all markers to the end of = the file reassign 34720 emacs submitter 34720 Ian Dunn severity 34720 normal tag 34720 fixed confirmed thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 03 10:28:52 2019 Received: (at submit) by debbugs.gnu.org; 3 Mar 2019 15:28:52 +0000 Received: from localhost ([127.0.0.1]:58634 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0T2p-00032b-U3 for submit@debbugs.gnu.org; Sun, 03 Mar 2019 10:28:52 -0500 Received: from eggs.gnu.org ([209.51.188.92]:42615) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0T2n-00032N-PD for submit@debbugs.gnu.org; Sun, 03 Mar 2019 10:28:50 -0500 Received: from lists.gnu.org ([209.51.188.17]:44395) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h0T2i-0000vt-Kb for submit@debbugs.gnu.org; Sun, 03 Mar 2019 10:28:44 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56996) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h0T2h-0007Nr-TM for bug-gnu-emacs@gnu.org; Sun, 03 Mar 2019 10:28:44 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=ALL_TRUSTED,BAYES_05 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59192) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h0T2h-0000v2-Lx for bug-gnu-emacs@gnu.org; Sun, 03 Mar 2019 10:28:43 -0500 Received: from [2604:6000:1006:8195:229c:c3cf:46a4:839a] (port=55392 helo=escafil) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h0T2g-00035t-9H for bug-gnu-emacs@gnu.org; Sun, 03 Mar 2019 10:28:43 -0500 From: Ian Dunn To: bug-gnu-emacs@gnu.org Subject: 26.1; Reverting a GPG buffer moves all markers to the end of the file Date: Sun, 03 Mar 2019 10:28:41 -0500 Message-ID: <87a7ic9due.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) When I use `revert-buffer' on a buffer for a file encrypted with GnuPG, every marker in the buffer is moved to the end of the buffer. A normal file restores markers to their original positions after reverting. To replicate: 1. Open a GnuPG encrypted file 2. Run the following: (setq test-marker (make-marker)) (move-marker test-marker (point-marker)) ;; test-marker points to `point' 3. Revert the buffer ;; test-marker now points to the end of the buffer -- Ian Dunn From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 09 12:33:18 2019 Received: (at 34720) by debbugs.gnu.org; 9 Jul 2019 16:33:18 +0000 Received: from localhost ([127.0.0.1]:33995 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hkt3O-000245-20 for submit@debbugs.gnu.org; Tue, 09 Jul 2019 12:33:18 -0400 Received: from quimby.gnus.org ([80.91.231.51]:49216) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hkt3M-00023w-7q for 34720@debbugs.gnu.org; Tue, 09 Jul 2019 12:33:16 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hkt3I-0007AM-83; Tue, 09 Jul 2019 18:33:14 +0200 From: Lars Ingebrigtsen To: Ian Dunn Subject: Re: bug#34720: 26.1; Reverting a GPG buffer moves all markers to the end of the file References: <87a7ic9due.fsf@gnu.org> Date: Tue, 09 Jul 2019 18:33:11 +0200 In-Reply-To: <87a7ic9due.fsf@gnu.org> (Ian Dunn's message of "Sun, 03 Mar 2019 10:28:41 -0500") Message-ID: <87muhnrwvs.fsf@mouse.gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Ian Dunn writes: > When I use `revert-buffer' on a buffer for a file encrypted with > GnuPG, every marker in the buffer is moved to the end of the buffer. > A normal file restores markers to their original positions a [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34720 Cc: 34720@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Ian Dunn writes: > When I use `revert-buffer' on a buffer for a file encrypted with > GnuPG, every marker in the buffer is moved to the end of the buffer. > A normal file restores markers to their original positions after > reverting. > > To replicate: > > 1. Open a GnuPG encrypted file > 2. Run the following: > (setq test-marker (make-marker)) > (move-marker test-marker (point-marker)) > ;; test-marker points to `point' > 3. Revert the buffer > ;; test-marker now points to the end of the buffer I can confirm that this bug is still present in Emacs 27 -- but only if point is not at point-min, oddly enough. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 09 12:33:24 2019 Received: (at control) by debbugs.gnu.org; 9 Jul 2019 16:33:24 +0000 Received: from localhost ([127.0.0.1]:33998 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hkt3U-00024R-BI for submit@debbugs.gnu.org; Tue, 09 Jul 2019 12:33:24 -0400 Received: from quimby.gnus.org ([80.91.231.51]:49230) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hkt3S-00024I-Cu for control@debbugs.gnu.org; Tue, 09 Jul 2019 12:33:22 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hkt3P-0007AU-Qx for control@debbugs.gnu.org; Tue, 09 Jul 2019 18:33:21 +0200 Date: Tue, 09 Jul 2019 18:33:19 +0200 Message-Id: <87lfx7rwvk.fsf@mouse.gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #34720 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 34720 + confirmed quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tags 34720 + confirmed quit From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 26 03:20:38 2019 Received: (at 34720) by debbugs.gnu.org; 26 Aug 2019 07:20:38 +0000 Received: from localhost ([127.0.0.1]:45503 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i29Ir-0002TI-MR for submit@debbugs.gnu.org; Mon, 26 Aug 2019 03:20:38 -0400 Received: from quimby.gnus.org ([80.91.231.51]:49272) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i29Ip-0002T8-Ln for 34720@debbugs.gnu.org; Mon, 26 Aug 2019 03:20:36 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i29Ij-0004iC-Uk; Mon, 26 Aug 2019 09:20:33 +0200 From: Lars Ingebrigtsen To: Ian Dunn Subject: Re: bug#34720: 26.1; Reverting a GPG buffer moves all markers to the end of the file References: <87a7ic9due.fsf@gnu.org> <87muhnrwvs.fsf@mouse.gnus.org> Date: Mon, 26 Aug 2019 09:20:29 +0200 In-Reply-To: <87muhnrwvs.fsf@mouse.gnus.org> (Lars Ingebrigtsen's message of "Tue, 09 Jul 2019 18:33:11 +0200") Message-ID: <875zmk5r5u.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Lars Ingebrigtsen writes: >> 1. Open a GnuPG encrypted file >> 2. Run the following: >> (setq test-marker (make-marker)) >> (move-marker test-marker (point-marker)) >> ; ; test-marker points to `point' >> 3. Revert the buffer > [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34720 Cc: 34720@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Lars Ingebrigtsen writes: >> 1. Open a GnuPG encrypted file >> 2. Run the following: >> (setq test-marker (make-marker)) >> (move-marker test-marker (point-marker)) >> ;; test-marker points to `point' >> 3. Revert the buffer >> ;; test-marker now points to the end of the buffer I took a stab at this with the patch below (which is the wrong solution because it doesn't clear the undo list etc). But I don't quite understand why this is so much work. :-) The problem is twofold: The first is in epa.el itself, which deletes and then inserts, which destroys the markers. The second is the call to `decode-coding-region' in `decode-coding-inserted-region', which also destroys the markers. The third is that the interface to the new replace-buffer-contents function is really awkward -- it only takes a buffer as its SOURCE, which means that if you want to feed it something, you have to skip around to temporary buffers instead of feeding it a string, which would be natural. You have to be a with-temp-buffer/with-current-buffer/let contortionist to get it to be safe. And replace-buffer-contents does so much more than just restoring markers, anyway, so I'm not sure it's the right solution here, anyway. 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? (Unless such a macro exists somewhere already.) diff --git a/lisp/epa-file.el b/lisp/epa-file.el index d9886d3d67..03f53c40a9 100644 --- a/lisp/epa-file.el +++ b/lisp/epa-file.el @@ -24,6 +24,7 @@ (require 'epa) (require 'epa-hook) +(require 'mule) (defcustom epa-file-cache-passphrase-for-symmetric-encryption nil "If non-nil, cache passphrase for symmetric encryption. @@ -102,16 +103,21 @@ epa-file-run-real-handler (apply operation args))) (defun epa-file-decode-and-insert (string file visit beg end replace) - (if (fboundp 'decode-coding-inserted-region) - (save-restriction - (narrow-to-region (point) (point)) - (insert string) - (decode-coding-inserted-region - (point-min) (point-max) - (substring file 0 (string-match epa-file-name-regexp file)) - visit beg end replace)) - (insert (epa-file--decode-coding-string string (or coding-system-for-read - 'undecided))))) + (let ((buffer (current-buffer))) + (with-temp-buffer + (insert string) + (let ((coding (decode-coding-inserted-region-coding-system + (substring + file 0 (string-match epa-file-name-regexp file)) + visit beg end replace))) + (if coding + (decode-coding-region (point-min) (point-max) coding) + (setq last-coding-system-used coding)) + (let ((temp (current-buffer))) + (with-current-buffer buffer + (if replace + (replace-buffer-contents temp) + (insert-buffer-substring temp)))))))) (defvar epa-file-error nil) (defun epa-file--find-file-not-found-function () @@ -147,8 +153,6 @@ epa-file-insert-file-contents (format "Decrypting %s" file))) (unwind-protect (progn - (if replace - (goto-char (point-min))) (condition-case error (setq string (epg-decrypt-file context local-file nil)) (error @@ -187,12 +191,9 @@ epa-file-insert-file-contents ;; really edit the buffer. (let ((buffer-file-name (if visit nil buffer-file-name))) - (save-restriction - (narrow-to-region (point) (point)) - (epa-file-decode-and-insert string file visit beg end replace) - (setq length (- (point-max) (point-min)))) - (if replace - (delete-region (point) (point-max)))) + (setq length + (epa-file-decode-and-insert + string file visit beg end replace))) (if visit (set-visited-file-modtime)))) (if (and local-copy diff --git a/lisp/international/mule.el b/lisp/international/mule.el index ec6f647688..5338e54cf6 100644 --- a/lisp/international/mule.el +++ b/lisp/international/mule.el @@ -2244,6 +2244,25 @@ modify-coding-system-alist (cons (cons regexp coding-system) network-coding-system-alist))))))) +(defun decode-coding-inserted-region-coding-system (filename + visit beg end replace) + "Return a coding system for the current buffer as if it is read from FILENAME." + (let ((coding coding-system-for-read)) + (unless coding + (setq coding (funcall set-auto-coding-function + filename (- (point-max) (point-min))))) + (unless coding + (setq coding (car (find-operation-coding-system + 'insert-file-contents + (cons filename (current-buffer)) + visit beg end replace)))) + (if (coding-system-p coding) + (or enable-multibyte-characters + (setq coding + (coding-system-change-text-conversion coding 'raw-text))) + (setq coding nil)) + coding)) + (defun decode-coding-inserted-region (from to filename &optional visit beg end replace) "Decode the region between FROM and TO as if it is read from file FILENAME. @@ -2253,8 +2272,7 @@ decode-coding-inserted-region Part of the job of this function is setting `buffer-undo-list' appropriately." (save-excursion (save-restriction - (let ((coding coding-system-for-read) - undo-list-saved) + (let (coding undo-list-saved) (if visit ;; Temporarily turn off undo recording, if we're decoding the ;; text of a visited file. @@ -2268,19 +2286,8 @@ decode-coding-inserted-region buffer-undo-list t)))) (narrow-to-region from to) (goto-char (point-min)) - (or coding - (setq coding (funcall set-auto-coding-function - filename (- (point-max) (point-min))))) - (or coding - (setq coding (car (find-operation-coding-system - 'insert-file-contents - (cons filename (current-buffer)) - visit beg end replace)))) - (if (coding-system-p coding) - (or enable-multibyte-characters - (setq coding - (coding-system-change-text-conversion coding 'raw-text))) - (setq coding nil)) + (setq coding (decode-coding-inserted-region-coding-system + filename visit beg end replace)) (if coding (decode-coding-region (point-min) (point-max) coding) (setq last-coding-system-used coding)) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 26 03:59:25 2019 Received: (at 34720) by debbugs.gnu.org; 26 Aug 2019 07:59:25 +0000 Received: from localhost ([127.0.0.1]:45534 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i29uP-0003Z7-2p for submit@debbugs.gnu.org; Mon, 26 Aug 2019 03:59:25 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34784) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i29uN-0003Ys-W4 for 34720@debbugs.gnu.org; Mon, 26 Aug 2019 03:59:24 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:35699) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i29uI-00061f-O7; Mon, 26 Aug 2019 03:59:18 -0400 Received: from [176.228.60.248] (port=4598 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i29uH-0001yv-B6; Mon, 26 Aug 2019 03:59:18 -0400 Date: Mon, 26 Aug 2019 10:59:18 +0300 Message-Id: <83sgpofjc9.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-reply-to: <875zmk5r5u.fsf@gnus.org> (message from Lars Ingebrigtsen on Mon, 26 Aug 2019 09:20:29 +0200) Subject: Re: bug#34720: 26.1; Reverting a GPG buffer moves all markers to the end of the file References: <87a7ic9due.fsf@gnu.org> <87muhnrwvs.fsf@mouse.gnus.org> <875zmk5r5u.fsf@gnus.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34720 Cc: 34720@debbugs.gnu.org, dunni@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Date: Mon, 26 Aug 2019 09:20:29 +0200 > Cc: 34720@debbugs.gnu.org > > Lars Ingebrigtsen writes: > > >> 1. Open a GnuPG encrypted file > >> 2. Run the following: > >> (setq test-marker (make-marker)) > >> (move-marker test-marker (point-marker)) > >> ;; test-marker points to `point' > >> 3. Revert the buffer > >> ;; test-marker now points to the end of the buffer Markers cannot be preserved in every situation, there's no way around this basic fact. > The third is that the interface to the new replace-buffer-contents > function is really awkward -- it only takes a buffer as its SOURCE, > which means that if you want to feed it something, you have to skip > around to temporary buffers instead of feeding it a string, which would > be natural. You have to be a with-temp-buffer/with-current-buffer/let > contortionist to get it to be safe. 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? > 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? From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 26 04:14:18 2019 Received: (at 34720) by debbugs.gnu.org; 26 Aug 2019 08:14:18 +0000 Received: from localhost ([127.0.0.1]:45543 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i2A8n-0003wL-Sc for submit@debbugs.gnu.org; Mon, 26 Aug 2019 04:14:18 -0400 Received: from quimby.gnus.org ([80.91.231.51]:49836) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i2A8k-0003wB-EU for 34720@debbugs.gnu.org; Mon, 26 Aug 2019 04:14:16 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i2A8g-0005A5-Ij; Mon, 26 Aug 2019 10:14:13 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#34720: 26.1; Reverting a GPG buffer moves all markers to the end of the file References: <87a7ic9due.fsf@gnu.org> <87muhnrwvs.fsf@mouse.gnus.org> <875zmk5r5u.fsf@gnus.org> <83sgpofjc9.fsf@gnu.org> Date: Mon, 26 Aug 2019 10:14:10 +0200 In-Reply-To: <83sgpofjc9.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 26 Aug 2019 10:59:18 +0300") Message-ID: <87k1b04a3x.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: 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. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34720 Cc: 34720@debbugs.gnu.org, dunni@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. > 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? 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. 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.) >> 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. Which is what replace-buffer-contents does, but for a whole lot more stuff. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 26 05:42:10 2019 Received: (at 34720) by debbugs.gnu.org; 26 Aug 2019 09:42:11 +0000 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 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 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 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 Date: Mon, 26 Aug 2019 12:42:03 +0300 Message-Id: <83pnksfel0.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-reply-to: <87k1b04a3x.fsf@gnus.org> (message from Lars Ingebrigtsen on Mon, 26 Aug 2019 10:14:10 +0200) Subject: Re: bug#34720: 26.1; Reverting a GPG buffer moves all markers to the end of the file References: <87a7ic9due.fsf@gnu.org> <87muhnrwvs.fsf@mouse.gnus.org> <875zmk5r5u.fsf@gnus.org> <83sgpofjc9.fsf@gnu.org> <87k1b04a3x.fsf@gnus.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34720 Cc: 34720@debbugs.gnu.org, dunni@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 27 03:14:28 2019 Received: (at 34720) by debbugs.gnu.org; 27 Aug 2019 07:14:28 +0000 Received: from localhost ([127.0.0.1]:47571 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i2VgS-00022P-Gy for submit@debbugs.gnu.org; Tue, 27 Aug 2019 03:14:28 -0400 Received: from quimby.gnus.org ([80.91.231.51]:37634) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i2VgQ-00022F-Pi for 34720@debbugs.gnu.org; Tue, 27 Aug 2019 03:14:27 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i2VgM-0004Zg-Id; Tue, 27 Aug 2019 09:14:25 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#34720: 26.1; Reverting a GPG buffer moves all markers to the end of the file 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> Date: Tue, 27 Aug 2019 09:14:22 +0200 In-Reply-To: <83pnksfel0.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 26 Aug 2019 12:42:03 +0300") Message-ID: <87v9uj2i7l.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: 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. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34720 Cc: 34720@debbugs.gnu.org, dunni@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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); 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 27 04:00:17 2019 Received: (at 34720) by debbugs.gnu.org; 27 Aug 2019 08:00:17 +0000 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 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 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 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 Date: Tue, 27 Aug 2019 11:00:09 +0300 Message-Id: <83mufvdomu.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-reply-to: <87v9uj2i7l.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 27 Aug 2019 09:14:22 +0200) Subject: Re: bug#34720: 26.1; Reverting a GPG buffer moves all markers to the end of the file 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> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34720 Cc: 34720@debbugs.gnu.org, dunni@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 27 04:23:39 2019 Received: (at 34720) by debbugs.gnu.org; 27 Aug 2019 08:23:39 +0000 Received: from localhost ([127.0.0.1]:47653 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i2WlO-0007vL-TV for submit@debbugs.gnu.org; Tue, 27 Aug 2019 04:23:39 -0400 Received: from quimby.gnus.org ([80.91.231.51]:38656) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i2WlK-0007v8-Hy for 34720@debbugs.gnu.org; Tue, 27 Aug 2019 04:23:34 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i2WlF-0006z3-Ct; Tue, 27 Aug 2019 10:23:32 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#34720: 26.1; Reverting a GPG buffer moves all markers to the end of the file 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> <83mufvdomu.fsf@gnu.org> Date: Tue, 27 Aug 2019 10:23:28 +0200 In-Reply-To: <83mufvdomu.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 27 Aug 2019 11:00:09 +0300") Message-ID: <87ftln2f0f.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > 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 [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34720 Cc: 34720@debbugs.gnu.org, dunni@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > 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). Hm. Doesn't the code below restore all markers (that it can restore)? static void restore_window_points (Lisp_Object window_markers, ptrdiff_t inserted, ptrdiff_t same_at_start, ptrdiff_t same_at_end) { for (; CONSP (window_markers); window_markers = XCDR (window_markers)) if (CONSP (XCAR (window_markers))) { Lisp_Object car = XCAR (window_markers); Lisp_Object marker = XCAR (car); Lisp_Object oldpos = XCDR (car); if (MARKERP (marker) && FIXNUMP (oldpos) && XFIXNUM (oldpos) > same_at_start && XFIXNUM (oldpos) < same_at_end) { ptrdiff_t oldsize = same_at_end - same_at_start; ptrdiff_t newsize = inserted; double growth = newsize / (double)oldsize; ptrdiff_t newpos = same_at_start + growth * (XFIXNUM (oldpos) - same_at_start); Fset_marker (marker, make_fixnum (newpos), Qnil); } } } And I just tested with the test case in this bug report, which is (progn (setq test-marker (make-marker)) (move-marker test-marker (point))) append to the file, and then `M-x revert-buffer': test-marker remains at the same position. So I think Finsert_file_contents really restores (for some value of "restores") all the markers? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 27 04:37:47 2019 Received: (at 34720) by debbugs.gnu.org; 27 Aug 2019 08:37:47 +0000 Received: from localhost ([127.0.0.1]:47663 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i2Wz5-0008Fc-JY for submit@debbugs.gnu.org; Tue, 27 Aug 2019 04:37:47 -0400 Received: from quimby.gnus.org ([80.91.231.51]:38862) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i2Wz4-0008FT-1b for 34720@debbugs.gnu.org; Tue, 27 Aug 2019 04:37:46 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i2Wyz-00078O-7T; Tue, 27 Aug 2019 10:37:43 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#34720: 26.1; Reverting a GPG buffer moves all markers to the end of the file 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> <83mufvdomu.fsf@gnu.org> Date: Tue, 27 Aug 2019 10:37:40 +0200 In-Reply-To: <83mufvdomu.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 27 Aug 2019 11:00:09 +0300") Message-ID: <87blwb2ecr.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: 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 po [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34720 Cc: 34720@debbugs.gnu.org, dunni@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 27 04:41:24 2019 Received: (at 34720) by debbugs.gnu.org; 27 Aug 2019 08:41:24 +0000 Received: from localhost ([127.0.0.1]:47667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i2X2a-0008Ks-5h for submit@debbugs.gnu.org; Tue, 27 Aug 2019 04:41:24 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58776) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i2X2Y-0008Kf-5i for 34720@debbugs.gnu.org; Tue, 27 Aug 2019 04:41:22 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:54764) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i2X2R-0000nP-Tg; Tue, 27 Aug 2019 04:41:16 -0400 Received: from [176.228.60.248] (port=4099 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i2X2Q-0000O4-5T; Tue, 27 Aug 2019 04:41:14 -0400 Date: Tue, 27 Aug 2019 11:41:16 +0300 Message-Id: <83imqjdmqb.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-reply-to: <87ftln2f0f.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 27 Aug 2019 10:23:28 +0200) Subject: Re: bug#34720: 26.1; Reverting a GPG buffer moves all markers to the end of the file 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> <83mufvdomu.fsf@gnu.org> <87ftln2f0f.fsf@gnus.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34720 Cc: 34720@debbugs.gnu.org, dunni@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: dunni@gnu.org, 34720@debbugs.gnu.org > Date: Tue, 27 Aug 2019 10:23:28 +0200 > > Eli Zaretskii writes: > > > 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). > > Hm. Doesn't the code below restore all markers (that it can restore)? No, it restores only the window-point marker in each window that shows the same buffer. See get_window_points_and_markers, which collects those markers. > And I just tested with the test case in this bug report, which is > > (progn > (setq test-marker (make-marker)) > (move-marker test-marker (point))) > > append to the file, and then `M-x revert-buffer': test-marker remains at > the same position. Must be sheer luck. Or maybe I'm missing something, but you will have to show me the code that moves this test marker to convince me. (I don't have the necessary software installed to repeat the recipe myself.) From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 27 05:05:41 2019 Received: (at 34720) by debbugs.gnu.org; 27 Aug 2019 09:05:41 +0000 Received: from localhost ([127.0.0.1]:47671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i2XQ5-0000Rr-AF for submit@debbugs.gnu.org; Tue, 27 Aug 2019 05:05:41 -0400 Received: from quimby.gnus.org ([80.91.231.51]:39256) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i2XQ2-0000Rg-DS for 34720@debbugs.gnu.org; Tue, 27 Aug 2019 05:05:38 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i2XPy-0007L9-8Z; Tue, 27 Aug 2019 11:05:36 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#34720: 26.1; Reverting a GPG buffer moves all markers to the end of the file 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> <83mufvdomu.fsf@gnu.org> <87ftln2f0f.fsf@gnus.org> <83imqjdmqb.fsf@gnu.org> Date: Tue, 27 Aug 2019 11:05:33 +0200 In-Reply-To: <83imqjdmqb.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 27 Aug 2019 11:41:16 +0300") Message-ID: <877e6z2d2a.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > Must be sheer luck. Or maybe I'm missing something, but you will have > to show me the code that moves this test marker to convince me. (I > don't have the necessary software installed to repeat the [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34720 Cc: 34720@debbugs.gnu.org, dunni@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > Must be sheer luck. Or maybe I'm missing something, but you will have > to show me the code that moves this test marker to convince me. (I > don't have the necessary software installed to repeat the recipe myself.) (progn (find-file "/tmp/foo.txt") (kill-buffer (current-buffer)) (when (file-exists-p "/tmp/foo.txt") (delete-file "/tmp/foo.txt")) (find-file "/tmp/foo.txt") (insert "Test line.") (setq test-marker1 (make-marker)) (move-marker test-marker1 4) (setq test-marker2 (make-marker)) (move-marker test-marker2 5) (save-buffer t) (shell-command "echo new >> /tmp/foo.txt") (revert-buffer nil t) (list test-marker1 test-marker2)) => (# #) So the markers seem to be restored on `revert-buffer'? The reason this doesn't happen in the epa case seems to be a bug in Finsert_file_contents: When there's an external handler, it skips directly to handled: and neglects to do the same_at_start computation, which leaves that at point-min and restore_window_points ignores all markers that have values that are larger than same_at_start. If I'm reading the code right. If the new text doesn't match the old text, the markers are not restored: (progn (find-file "/tmp/foo.txt") (kill-buffer (current-buffer)) (when (file-exists-p "/tmp/foo.txt") (delete-file "/tmp/foo.txt")) (find-file "/tmp/foo.txt") (insert "Test line.") (setq test-marker1 (make-marker)) (move-marker test-marker1 4) (setq test-marker2 (make-marker)) (move-marker test-marker2 5) (save-buffer t) (shell-command "echo Here is a new text > /tmp/foo.txt") (revert-buffer nil t) (list test-marker1 test-marker2)) (# #) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 27 05:15:36 2019 Received: (at 34720) by debbugs.gnu.org; 27 Aug 2019 09:15:36 +0000 Received: from localhost ([127.0.0.1]:47693 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i2XZg-0000g9-Dx for submit@debbugs.gnu.org; Tue, 27 Aug 2019 05:15:36 -0400 Received: from quimby.gnus.org ([80.91.231.51]:39402) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i2XZe-0000fz-9w for 34720@debbugs.gnu.org; Tue, 27 Aug 2019 05:15:34 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i2XZa-0007Rw-4Z; Tue, 27 Aug 2019 11:15:32 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#34720: 26.1; Reverting a GPG buffer moves all markers to the end of the file 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> <83mufvdomu.fsf@gnu.org> <87ftln2f0f.fsf@gnus.org> <83imqjdmqb.fsf@gnu.org> Date: Tue, 27 Aug 2019 11:15:29 +0200 In-Reply-To: <83imqjdmqb.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 27 Aug 2019 11:41:16 +0300") Message-ID: <8736hn2clq.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > No, it restores only the window-point marker in each window that shows > the same buffer. See get_window_points_and_markers, which collects > those markers. Oh, oh, you're totally right, of course -- that function only collects the point markers. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34720 Cc: 34720@debbugs.gnu.org, dunni@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > No, it restores only the window-point marker in each window that shows > the same buffer. See get_window_points_and_markers, which collects > those markers. Oh, oh, you're totally right, of course -- that function only collects the point markers. The reason the other markers magically survive Finsert_file_contents is because that function takes care not to replace any text in the buffer that's identical to the text already there? So the text isn't deleted, the markers stay where they are, and everything works nice. 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? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 27 05:17:19 2019 Received: (at 34720) by debbugs.gnu.org; 27 Aug 2019 09:17:19 +0000 Received: from localhost ([127.0.0.1]:47697 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i2XbK-0000j0-Pl for submit@debbugs.gnu.org; Tue, 27 Aug 2019 05:17:19 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36006) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i2XbG-0000im-Ug for 34720@debbugs.gnu.org; Tue, 27 Aug 2019 05:17:15 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55198) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i2XbB-0007nJ-Rm; Tue, 27 Aug 2019 05:17:09 -0400 Received: from [176.228.60.248] (port=2371 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i2XbA-0004VR-R5; Tue, 27 Aug 2019 05:17:09 -0400 Date: Tue, 27 Aug 2019 12:17:11 +0300 Message-Id: <83h863dl2g.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-reply-to: <877e6z2d2a.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 27 Aug 2019 11:05:33 +0200) Subject: Re: bug#34720: 26.1; Reverting a GPG buffer moves all markers to the end of the file 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> <83mufvdomu.fsf@gnu.org> <87ftln2f0f.fsf@gnus.org> <83imqjdmqb.fsf@gnu.org> <877e6z2d2a.fsf@gnus.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34720 Cc: 34720@debbugs.gnu.org, dunni@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: dunni@gnu.org, 34720@debbugs.gnu.org > Date: Tue, 27 Aug 2019 11:05:33 +0200 > > (progn > (find-file "/tmp/foo.txt") > (kill-buffer (current-buffer)) > (when (file-exists-p "/tmp/foo.txt") > (delete-file "/tmp/foo.txt")) > (find-file "/tmp/foo.txt") > (insert "Test line.") > (setq test-marker1 (make-marker)) > (move-marker test-marker1 4) > (setq test-marker2 (make-marker)) > (move-marker test-marker2 5) > (save-buffer t) > (shell-command "echo new >> /tmp/foo.txt") > (revert-buffer nil t) > (list test-marker1 test-marker2)) > > => (# #) > > So the markers seem to be restored on `revert-buffer'? The original text is unchanged, you just added something at the end of the file. So markers at positions 4 and 5 will be preserved, yes. > The reason this doesn't happen in the epa case seems to be a bug in > Finsert_file_contents: When there's an external handler, it skips > directly to handled: and neglects to do the same_at_start computation, > which leaves that at point-min and restore_window_points ignores all > markers that have values that are larger than same_at_start. AFAIU, the problem with the epa case is that the buffer is erased and the text re-inserted. Isn't that the case? In any case, how can insert-file-contents know what the handler did wrt which part(s) of the buffer remained unchanged? > If the new text doesn't match the old text, the markers are not > restored: Of course. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 27 06:20:30 2019 Received: (at 34720) by debbugs.gnu.org; 27 Aug 2019 10:20:30 +0000 Received: from localhost ([127.0.0.1]:47734 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i2YaU-0002Bn-Bb for submit@debbugs.gnu.org; Tue, 27 Aug 2019 06:20:30 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49079) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i2YaS-0002Ba-3V for 34720@debbugs.gnu.org; Tue, 27 Aug 2019 06:20:28 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55797) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i2YaM-0007sA-Pl; Tue, 27 Aug 2019 06:20:22 -0400 Received: from [176.228.60.248] (port=2396 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i2YaL-0003Kt-7w; Tue, 27 Aug 2019 06:20:21 -0400 Date: Tue, 27 Aug 2019 13:20:24 +0300 Message-Id: <83ef16ewpj.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-reply-to: <8736hn2clq.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 27 Aug 2019 11:15:29 +0200) Subject: Re: bug#34720: 26.1; Reverting a GPG buffer moves all markers to the end of the file 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> <83mufvdomu.fsf@gnu.org> <87ftln2f0f.fsf@gnus.org> <83imqjdmqb.fsf@gnu.org> <8736hn2clq.fsf@gnus.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34720 Cc: 34720@debbugs.gnu.org, dunni@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: 34720@debbugs.gnu.org, dunni@gnu.org > Date: Tue, 27 Aug 2019 11:15:29 +0200 > > The reason the other markers magically survive Finsert_file_contents is > because that function takes care not to replace any text in the buffer > that's identical to the text already there? So the text isn't deleted, > the markers stay where they are, and everything works nice. Right. > 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? From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 30 05:48:12 2019 Received: (at 34720) by debbugs.gnu.org; 30 Aug 2019 09:48:12 +0000 Received: from localhost ([127.0.0.1]:53318 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i3dVs-0000qg-87 for submit@debbugs.gnu.org; Fri, 30 Aug 2019 05:48:12 -0400 Received: from quimby.gnus.org ([80.91.231.51]:39376) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i3dVr-0000qW-87 for 34720@debbugs.gnu.org; Fri, 30 Aug 2019 05:48:11 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i3dVn-0000Qr-TY; Fri, 30 Aug 2019 11:48:10 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#34720: 26.1; Reverting a GPG buffer moves all markers to the end of the file 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> <83mufvdomu.fsf@gnu.org> <87ftln2f0f.fsf@gnus.org> <83imqjdmqb.fsf@gnu.org> <8736hn2clq.fsf@gnus.org> <83ef16ewpj.fsf@gnu.org> Date: Fri, 30 Aug 2019 11:48:07 +0200 In-Reply-To: <83ef16ewpj.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 27 Aug 2019 13:20:24 +0300") Message-ID: <87k1avhtm0.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii 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 [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34720 Cc: 34720@debbugs.gnu.org, dunni@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii 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. :-) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 30 06:21:47 2019 Received: (at 34720) by debbugs.gnu.org; 30 Aug 2019 10:21:47 +0000 Received: from localhost ([127.0.0.1]:53332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i3e2N-0001eg-5o for submit@debbugs.gnu.org; Fri, 30 Aug 2019 06:21:47 -0400 Received: from quimby.gnus.org ([80.91.231.51]:39878) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i3e2L-0001eV-5f for 34720@debbugs.gnu.org; Fri, 30 Aug 2019 06:21:45 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i3e2G-0000fl-Jw; Fri, 30 Aug 2019 12:21:43 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#34720: 26.1; Reverting a GPG buffer moves all markers to the end of the file 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> <83mufvdomu.fsf@gnu.org> <87ftln2f0f.fsf@gnus.org> <83imqjdmqb.fsf@gnu.org> <8736hn2clq.fsf@gnus.org> <83ef16ewpj.fsf@gnu.org> <87k1avhtm0.fsf@gnus.org> Date: Fri, 30 Aug 2019 12:21:40 +0200 In-Reply-To: <87k1avhtm0.fsf@gnus.org> (Lars Ingebrigtsen's message of "Fri, 30 Aug 2019 11:48:07 +0200") Message-ID: <875zmfhs23.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: That didn't seem to be too complicated, so I've now pushed the change. The original test case now works (i.e., more markers are now preserved, so it more closely emulates Finsert_file_contents). -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34720 Cc: 34720@debbugs.gnu.org, dunni@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) That didn't seem to be too complicated, so I've now pushed the change. The original test case now works (i.e., more markers are now preserved, so it more closely emulates Finsert_file_contents). -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 30 06:21:51 2019 Received: (at control) by debbugs.gnu.org; 30 Aug 2019 10:21:51 +0000 Received: from localhost ([127.0.0.1]:53335 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i3e2R-0001ex-Gb for submit@debbugs.gnu.org; Fri, 30 Aug 2019 06:21:51 -0400 Received: from quimby.gnus.org ([80.91.231.51]:39892) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i3e2Q-0001ep-4z for control@debbugs.gnu.org; Fri, 30 Aug 2019 06:21:50 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i3e2M-0000fs-Kg for control@debbugs.gnu.org; Fri, 30 Aug 2019 12:21:48 +0200 Date: Fri, 30 Aug 2019 12:21:46 +0200 Message-Id: <874l1zhs1x.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #34720 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 34720 fixed close 34720 27.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tags 34720 fixed close 34720 27.1 quit From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 30 09:22:52 2019 Received: (at 34720) by debbugs.gnu.org; 30 Aug 2019 13:22:52 +0000 Received: from localhost ([127.0.0.1]:53455 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i3grc-0001vn-ET for submit@debbugs.gnu.org; Fri, 30 Aug 2019 09:22:52 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57446) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i3grX-0001vR-Eb for 34720@debbugs.gnu.org; Fri, 30 Aug 2019 09:22:47 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40012) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i3grR-0003Bt-8K; Fri, 30 Aug 2019 09:22:41 -0400 Received: from [176.228.60.248] (port=4458 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i3fsW-0007Tz-85; Fri, 30 Aug 2019 08:19:44 -0400 Date: Fri, 30 Aug 2019 15:19:51 +0300 Message-Id: <83imqealqw.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-reply-to: <87k1avhtm0.fsf@gnus.org> (message from Lars Ingebrigtsen on Fri, 30 Aug 2019 11:48:07 +0200) Subject: Re: bug#34720: 26.1; Reverting a GPG buffer moves all markers to the end of the file 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> <83mufvdomu.fsf@gnu.org> <87ftln2f0f.fsf@gnus.org> <83imqjdmqb.fsf@gnu.org> <8736hn2clq.fsf@gnus.org> <83ef16ewpj.fsf@gnu.org> <87k1avhtm0.fsf@gnus.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34720 Cc: 34720@debbugs.gnu.org, dunni@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: 34720@debbugs.gnu.org, dunni@gnu.org > Date: Fri, 30 Aug 2019 11:48:07 +0200 > > Eli Zaretskii 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). From unknown Sun Jun 15 08:23:43 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 28 Sep 2019 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator