From unknown Sun Jul 27 05:59:56 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#78866 <78866@debbugs.gnu.org> To: bug#78866 <78866@debbugs.gnu.org> Subject: Status: [PATCH] (Finsert_file_contents): Refine commit d07af40d8826 Reply-To: bug#78866 <78866@debbugs.gnu.org> Date: Sun, 27 Jul 2025 12:59:56 +0000 retitle 78866 [PATCH] (Finsert_file_contents): Refine commit d07af40d8826 reassign 78866 emacs submitter 78866 Stefan Monnier severity 78866 normal tag 78866 patch thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 22 22:29:03 2025 Received: (at submit) by debbugs.gnu.org; 23 Jun 2025 02:29:03 +0000 Received: from localhost ([127.0.0.1]:51546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uTWve-0001HJ-PB for submit@debbugs.gnu.org; Sun, 22 Jun 2025 22:29:03 -0400 Received: from lists.gnu.org ([2001:470:142::17]:47296) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uTWvc-0001GG-C9 for submit@debbugs.gnu.org; Sun, 22 Jun 2025 22:29:01 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uTWvW-0006Tu-P6 for bug-gnu-emacs@gnu.org; Sun, 22 Jun 2025 22:28:54 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uTWvU-0001jr-Mj for bug-gnu-emacs@gnu.org; Sun, 22 Jun 2025 22:28:54 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 50A28441204 for ; Sun, 22 Jun 2025 22:28:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1750645727; bh=iMHrWaFxJA4s+Gm7X2rFXZyneAMlOFfVYzuXuldrH9g=; h=From:To:Subject:Date:From; b=X7WmuJ2uH6XOcGBKERtTCRaMDAZG5n0Gc1skmScKp3xAZ6MvNp+o/t1fy2aFsLCK/ LCWjWArHdJwSIURajcUUleXvDq93tKS6XLkzKjQfcLBUD/+ydSOlC4K2V3Gvx6vw/v fSl2Uk71ET51JEIdZ70lE2jF6jquFjxDRpX4BMz2/PvdgGGqU4hyr+Z25FzEbApBnW qSBTXzBNSe7t6e6s7q8fALGnjhF1ISTFEVH5UdiX4xRxWSugTFz0YyggFVXbEd7laC IvKttzWvWQ1Ef+q0SMT34wAOc1aNajliuL2/SI6HdBukg+lp/TSa9BNg1dGUUUBbXm uS6d1g2nMfsRw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 6C3CD4411F0 for ; Sun, 22 Jun 2025 22:28:47 -0400 (EDT) Received: from pastel (unknown [104.247.225.139]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 49954120682 for ; Sun, 22 Jun 2025 22:28:47 -0400 (EDT) From: Stefan Monnier To: bug-gnu-emacs@gnu.org Subject: [PATCH] (Finsert_file_contents): Refine commit d07af40d8826 X-Debbugs-Cc: Date: Sun, 22 Jun 2025 22:28:31 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.316 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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 (-) --=-=-= Content-Type: text/plain Tags: patch As requested in bug#78777, here's a separate bug report for the following problem: - Start with: % src/emacs -Q BUGS & % echo foo >>BUGS - In the Emacs session type: a Notice how Emacs correctly prompts about "changed on disk, really edit". Hit `C-g` so we don't actually edit the buffer. - In the Emacs session do: M-: (insert-file-contents "README" nil nil nil t) RET Notice how Emacs just blindly changed the contents of the buffer without prompting about "changed on disk, really edit". I think this last step is an error, we should be prompted just as we are with any other buffer modification that diverges from the file's contents. The patch below does just that, Stefan --=-=-= Content-Type: text/patch Content-Disposition: attachment; filename=0002-Finsert_file_contents-Refine-commit-d07af40d8826.patch >From 54c128dd5fa29293f10f6b8a667078285eddca0a Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Sun, 22 Jun 2025 22:25:03 -0400 Subject: [PATCH 2/2] (Finsert_file_contents): Refine commit d07af40d8826 * src/fileio.c (Finsert_file_contents): Inhibit ask-supersession only if we're VISITing. * test/src/fileio-tests.el (ert--tests-dir): New var. (fileio-tests--insert-file-contents-supersession): New test. --- src/fileio.c | 31 +++++++++++++++++++------------ test/src/fileio-tests.el | 26 ++++++++++++++++++++++++++ 2 files changed, 45 insertions(+), 12 deletions(-) diff --git a/src/fileio.c b/src/fileio.c index 7e1ac3fc383..39d577de7fe 100644 --- a/src/fileio.c +++ b/src/fileio.c @@ -4550,14 +4550,19 @@ DEFUN ("insert-file-contents", Finsert_file_contents, Sinsert_file_contents, beg_offset += same_at_start - BEGV_BYTE; end_offset -= ZV_BYTE - same_at_end; - /* This binding is to avoid ask-user-about-supersession-threat - being called in insert_from_buffer or del_range_bytes (via - prepare_to_modify_buffer). - AFAICT we could avoid ask-user-about-supersession-threat by setting - current_buffer->modtime earlier, but we could still end up calling - ask-user-about-supersession-threat if the file is modified while - we read it, so we bind buffer-file-name instead. */ - specbind (Qbuffer_file_name, Qnil); + if (!NILP (visit)) + /* This binding is to avoid ask-user-about-supersession-threat + being called in insert_from_buffer or del_range_bytes (via + prepare_to_modify_buffer). + Such a prompt makes no sense if we're VISITing the file, + since the insertion makes the buffer *more* like the file + rather than the reverse. + AFAICT we could avoid ask-user-about-supersession-threat by + setting current_buffer->modtime earlier, but we could still + end up calling ask-user-about-supersession-threat if the file + is modified while we read it, so we bind buffer-file-name + instead. */ + specbind (Qbuffer_file_name, Qnil); del_range_byte (same_at_start, same_at_end); /* Insert from the file at the proper position. */ temp = BYTE_TO_CHAR (same_at_start); @@ -4666,8 +4671,9 @@ DEFUN ("insert-file-contents", Finsert_file_contents, Sinsert_file_contents, /* Truncate the buffer to the size of the file. */ if (same_at_start != same_at_end) { - /* See previous specbind for the reason behind this. */ - specbind (Qbuffer_file_name, Qnil); + if (!NILP (visit)) + /* See previous specbind for the reason behind this. */ + specbind (Qbuffer_file_name, Qnil); del_range_byte (same_at_start, same_at_end); } inserted = 0; @@ -4716,8 +4722,9 @@ DEFUN ("insert-file-contents", Finsert_file_contents, Sinsert_file_contents, we are taking from the decoded string. */ inserted -= (ZV_BYTE - same_at_end) + (same_at_start - BEGV_BYTE); - /* See previous specbind for the reason behind this. */ - specbind (Qbuffer_file_name, Qnil); + if (!NILP (visit)) + /* See previous specbind for the reason behind this. */ + specbind (Qbuffer_file_name, Qnil); if (same_at_end != same_at_start) { del_range_byte (same_at_start, same_at_end); diff --git a/test/src/fileio-tests.el b/test/src/fileio-tests.el index 13cc5de29e8..b6302c35fee 100644 --- a/test/src/fileio-tests.el +++ b/test/src/fileio-tests.el @@ -235,5 +235,31 @@ fileio-tests-w32-time-stamp-granularity "2025/02/01 23:15:59.123456700"))) (delete-file tfile)))) +(defconst ert--tests-dir + (file-name-directory (macroexp-file-name))) + +(ert-deftest fileio-tests--insert-file-contents-supersession () + (ert-with-temp-file file + (write-region "foo" nil file) + (let* ((asked nil) + (buf (find-file-noselect file)) + (auast (lambda (&rest _) (setq asked t)))) + (unwind-protect + (with-current-buffer buf + ;; Pretend someone else edited the file. + (write-region "bar" nil file 'append) + ;; Use `advice-add' rather than `cl-letf' because the function + ;; may not be defined yet. + (advice-add 'ask-user-about-supersession-threat :override auast) + ;; Modify the local buffer via `insert-file-contents'. + (insert-file-contents + (expand-file-name "lread-resources/somelib.el" + ert--tests-dir) + nil nil nil 'replace)) + (advice-remove 'ask-user-about-supersession-threat auast) + (kill-buffer buf)) + ;; We should have prompted about the supersession threat. + (should asked)))) + ;;; fileio-tests.el ends here -- 2.39.5 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 26 05:10:03 2025 Received: (at 78866) by debbugs.gnu.org; 26 Jun 2025 09:10:04 +0000 Received: from localhost ([127.0.0.1]:48536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uUicN-0003Zh-9d for submit@debbugs.gnu.org; Thu, 26 Jun 2025 05:10:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40628) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uUicJ-0003Z2-Sq for 78866@debbugs.gnu.org; Thu, 26 Jun 2025 05:10:00 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uUicD-00016B-RR; Thu, 26 Jun 2025 05:09:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=wU6OHRceYury33jSe52qJo1sOPhvNce3ML4+ach3eC0=; b=SPAnOV2wzb04 9wBVMfDWNvc5+EcBwc3AXM7N98WBUyI1b9yrVu+82zmEJ3obyhwnASThdwWmm9g4tWFSohoDyKver GzDp0TBPLrEB80bT3yda+st/tBchTQr+WeTBAvNMiwhQWm+xsqXTBcOIqkIWRXS6LdPxPYXuJSD6q qRbB7s3LYXLIvhc+6KaGrG642UqnBO/YgqWrHwzJzAAB0/e4uC3enYR9havSmLk+K3W6RGzqdHbsS Celu8iueSUwgAZP2XJuL2r7QrU7RxaJS/X5Yr7axjpTKje+OOc7nwa6FB9IrMw21qnpQx2Xov8Nlr d1PKf8m/VZkMsqS2/snoUQ==; Date: Thu, 26 Jun 2025 12:09:49 +0300 Message-Id: <86bjqadg2q.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#78866: [PATCH] (Finsert_file_contents): Refine commit d07af40d8826 References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78866 Cc: 78866@debbugs.gnu.org, monnier@iro.umontreal.ca 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 (---) > Cc: > Date: Sun, 22 Jun 2025 22:28:31 -0400 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > - Start with: > > % src/emacs -Q BUGS & > % echo foo >>BUGS > > - In the Emacs session type: > > a > > Notice how Emacs correctly prompts about "changed on disk, really edit". > Hit `C-g` so we don't actually edit the buffer. > > - In the Emacs session do: > > M-: (insert-file-contents "README" nil nil nil t) RET > > Notice how Emacs just blindly changed the contents of the buffer > without prompting about "changed on disk, really edit". > > I think this last step is an error, we should be prompted just as we are > with any other buffer modification that diverges from the file's contents. > > The patch below does just that, I agree that we should prompt, but I don't understand the logic behind the proposed solution. Why is it OK not to prompt when VISIT is non-nil? It is true that in that case we will be reading from FILENAME, but the contents after the insertion will not necessarily be identical to FILENAME, because not necessarily the entire contents of the buffer is erased. The case where the entire buffer is erased and its contents replaced by that of FILENAME, in which case the prompt indeed makes no sense, is a special case, not the general case. Also note that the prompt, if we issue it here, will not be about FILENAME, it will be about the file visited by the buffer, which at this point is still the original buffer-file-name. In your example above, it's "BUGS", not "README". Which is wrong when VISIT is non-nil, but the correct solution is not just disable the prompt, it's to issue the prompt about a different file, no? So I'd prefer to fix this more thoroughly and correctly. From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 26 09:38:27 2025 Received: (at 78866) by debbugs.gnu.org; 26 Jun 2025 13:38:27 +0000 Received: from localhost ([127.0.0.1]:49751 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uUmo6-0006qz-P6 for submit@debbugs.gnu.org; Thu, 26 Jun 2025 09:38:27 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62406) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uUmo3-0006qL-12 for 78866@debbugs.gnu.org; Thu, 26 Jun 2025 09:38:23 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B9F6F440829; Thu, 26 Jun 2025 09:38:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1750945095; bh=DYcKdLPL1/Xwhv1td/x7BAsHlGo1AJRS7xod879uUj4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=idj4vZxWUgUqCjnvz33ql4rv+h7evYaLQOIfpn7G7kEsF5Mo//dMSTm4rItSmjEeD KOPf4W5oAo+RuwtLQMqc8Fa5mzvRxMis2WHB/VRYECvqknp50XEMzUyspBECsZo5XZ 9XxwRW1DIDCG+yLYrUnzqzttA5ey82mZ4JL1/BKo7msducA/dAgRmoNs1i65ArIlTQ wBx4QQUtwfGIhgeWfJYES2KxrJ1TDtDlqdyuwojjiTtD1/M7tR4wY/fsvmCA18igTS EPHG4OdrAKiGya1epeKMKivADPXqa3ZgNY1QWQGKohv2vjUQqYJaiLjRm+2sLGPQK1 XDEAa0KByiOtg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9C9B0440C6B; Thu, 26 Jun 2025 09:38:15 -0400 (EDT) Received: from pastel (unknown [104.247.225.139]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7284C12063F; Thu, 26 Jun 2025 09:38:15 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#78866: [PATCH] (Finsert_file_contents): Refine commit d07af40d8826 In-Reply-To: <86bjqadg2q.fsf@gnu.org> Message-ID: References: <86bjqadg2q.fsf@gnu.org> Date: Thu, 26 Jun 2025 09:38:14 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.302 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78866 Cc: 78866@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: -3.3 (---) > I agree that we should prompt, but I don't understand the logic behind > the proposed solution. Why is it OK not to prompt when VISIT is > non-nil? It is true that in that case we will be reading from > FILENAME, but the contents after the insertion will not necessarily be > identical to FILENAME, because not necessarily the entire contents of > the buffer is erased. If VISIT is non-nil, then REPLACE is also non-nil (or irrelevant because the buffer is empty): if (!NILP (visit)) { if (!NILP (beg) || !NILP (end)) error ("Attempt to visit less than an entire file"); if (BEG < Z && NILP (replace)) error ("Cannot do file visiting in a non-empty buffer"); } - Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 26 09:44:22 2025 Received: (at 78866) by debbugs.gnu.org; 26 Jun 2025 13:44:23 +0000 Received: from localhost ([127.0.0.1]:49812 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uUmtp-0007E5-Nd for submit@debbugs.gnu.org; Thu, 26 Jun 2025 09:44:22 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49432) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uUmtm-0007DQ-0E for 78866@debbugs.gnu.org; Thu, 26 Jun 2025 09:44:18 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uUmtf-0004Rr-Im; Thu, 26 Jun 2025 09:44:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=s6d1A4H6OrHm+oBNONrTdBcySa4RIPd0mwhQVA453Zc=; b=PshXZLRHcwrZ i+U/DqTC8B8BSkoGMgHh/7jhybAJL0czP2w4AJh/HiOPgq0Swv4dgYXTUDk/lr2fFIGBA+JqhvkjZ e1xUpe/UqYO7cVSTCpSjq0CjicsYQzMGw1n5Yd9LKmnYIdaao1pLDAuMdCYC/rgN+tOwVV8uo5+98 TgIoF9NLh00UULpvc/Z944KIuhmrqLN4a5c1th9lGywVC2waBq0rJKWEvq4a/aPJpmMYd4ehtF6QN NoOrKZ1uM0ZakNWPiut3CD7zGZaJDBqjjnGtrBmb1q85cSW7v3qnU+rJvXe1O2lbf79suKqIoxUQ7 ktwgTK7QvRUKb12bX0fmZw==; Date: Thu, 26 Jun 2025 16:44:08 +0300 Message-Id: <86v7oibot3.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Thu, 26 Jun 2025 09:38:14 -0400) Subject: Re: bug#78866: [PATCH] (Finsert_file_contents): Refine commit d07af40d8826 References: <86bjqadg2q.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78866 Cc: 78866@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: -3.3 (---) > From: Stefan Monnier > Cc: 78866@debbugs.gnu.org > Date: Thu, 26 Jun 2025 09:38:14 -0400 > > > I agree that we should prompt, but I don't understand the logic behind > > the proposed solution. Why is it OK not to prompt when VISIT is > > non-nil? It is true that in that case we will be reading from > > FILENAME, but the contents after the insertion will not necessarily be > > identical to FILENAME, because not necessarily the entire contents of > > the buffer is erased. > > If VISIT is non-nil, then REPLACE is also non-nil (or irrelevant > because the buffer is empty): > > if (!NILP (visit)) > { > if (!NILP (beg) || !NILP (end)) > error ("Attempt to visit less than an entire file"); > if (BEG < Z && NILP (replace)) > error ("Cannot do file visiting in a non-empty buffer"); > } Sure, but REPLACE replaces only the accessible portion of the buffert, not all of it. From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 26 12:39:32 2025 Received: (at 78866) by debbugs.gnu.org; 26 Jun 2025 16:39:33 +0000 Received: from localhost ([127.0.0.1]:53241 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uUpdL-0006JE-P6 for submit@debbugs.gnu.org; Thu, 26 Jun 2025 12:39:32 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16839) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uUpdJ-0006IN-6m for 78866@debbugs.gnu.org; Thu, 26 Jun 2025 12:39:29 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 54FB244153C; Thu, 26 Jun 2025 12:39:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1750955962; bh=x/Uc+PKpUha45lamVvJdsWfIy9CR7PcW5y0oU7bQb/M=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=f6Q5ja7u3LiE7bgGMeeGmFkrwOMH3qCzqfzS6QuQ1A7GkCWag3vIpDn6ClttE24L7 e8X3J2wiW3bCHB7FeWQEw9YhtA2mOB9/msLK9tNCMLfKwak7A98FJMVNRAV/edrBg+ z4uKKPpeCgLYSqEEstdItB3AkQx9tRn8KrX0P80c/rMacGid4A2mId2mIG5Z5c1PC/ HonrQmkRtcA3/Hq9fMaUmCbV2O+UVWLcfcwD1le/pScXaLxhbtGDJBK3Du16KiFHQF ZZsU3K1PU1Ar47AwUno7arFPeHMnqv8oXWjLAsFFt3gASpihdWEj7Bcz3bMi5QGZ6Z pPHc0037Sambg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 46A14441533; Thu, 26 Jun 2025 12:39:22 -0400 (EDT) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3B96E120170; Thu, 26 Jun 2025 12:39:22 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#78866: [PATCH] (Finsert_file_contents): Refine commit d07af40d8826 In-Reply-To: <86v7oibot3.fsf@gnu.org> Message-ID: References: <86bjqadg2q.fsf@gnu.org> <86v7oibot3.fsf@gnu.org> Date: Thu, 26 Jun 2025 12:39:14 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.160 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78866 Cc: 78866@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: -3.3 (---) >> > I agree that we should prompt, but I don't understand the logic behind >> > the proposed solution. Why is it OK not to prompt when VISIT is >> > non-nil? It is true that in that case we will be reading from >> > FILENAME, but the contents after the insertion will not necessarily be >> > identical to FILENAME, because not necessarily the entire contents of >> > the buffer is erased. >> If VISIT is non-nil, then REPLACE is also non-nil (or irrelevant >> because the buffer is empty): >> >> if (!NILP (visit)) >> { >> if (!NILP (beg) || !NILP (end)) >> error ("Attempt to visit less than an entire file"); >> if (BEG < Z && NILP (replace)) >> error ("Cannot do file visiting in a non-empty buffer"); >> } > > Sure, but REPLACE replaces only the accessible portion of the buffert, > not all of it. Then we should tighten the check even further. Instead of just adding if (!NILP (visit)) we should additionally check that BEG==BEGV and Z==ZV: if (!NILP (visit) && BEG == BEGV && Z == ZV) Tho, maybe the `BEG == BEGV && Z == ZV` check should be performed in the above quoted sanity check, because I think using a non-nil VISIT within a narrowed buffer goes against the intention of VISIT. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 26 12:51:44 2025 Received: (at 78866) by debbugs.gnu.org; 26 Jun 2025 16:51:45 +0000 Received: from localhost ([127.0.0.1]:53257 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uUpp8-00085T-J2 for submit@debbugs.gnu.org; Thu, 26 Jun 2025 12:51:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43018) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uUpp5-00084d-DJ for 78866@debbugs.gnu.org; Thu, 26 Jun 2025 12:51:40 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uUpoz-0003Kq-MP; Thu, 26 Jun 2025 12:51:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Ry0s1Eo40KuE1EcW00SYC9H2Ks5E8Q8M8+cTQtPvXRU=; b=COWXSlhkw6To nLRhMuuxxRvpuDVRrucTSkFBnejhLOT09tJWhHjqKaeckxQD9JoTBkvYBQO7zCHgRgcw6QW+rmeYV 3siMuj4ublZ/7DHp746WZECUtRVreIb7eB1iHTfLgnB7J7rV7bkzEdRdkjHjYruvAPv8XWw9qSntG Rt2sGNQpW3/40TotteYNhcwEBCE7x1OUj1wP6iawSJB4f9SPgHNWAwLMeRXrFtL6HDWrM02K5T9yi Bd/pR7nGQO3+0m0RjwhPxnLtgnBWTl3FYfxnru4x64v8W7D4pOoYfbFN3v3h8cgSrUlFnIcbc42ma Pyl9Bk2Vb7v1qji2DGe4Mw==; Date: Thu, 26 Jun 2025 19:51:31 +0300 Message-Id: <86jz4ybg4s.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Thu, 26 Jun 2025 12:39:14 -0400) Subject: Re: bug#78866: [PATCH] (Finsert_file_contents): Refine commit d07af40d8826 References: <86bjqadg2q.fsf@gnu.org> <86v7oibot3.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78866 Cc: 78866@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: -3.3 (---) > From: Stefan Monnier > Cc: 78866@debbugs.gnu.org > Date: Thu, 26 Jun 2025 12:39:14 -0400 > > >> If VISIT is non-nil, then REPLACE is also non-nil (or irrelevant > >> because the buffer is empty): > >> > >> if (!NILP (visit)) > >> { > >> if (!NILP (beg) || !NILP (end)) > >> error ("Attempt to visit less than an entire file"); > >> if (BEG < Z && NILP (replace)) > >> error ("Cannot do file visiting in a non-empty buffer"); > >> } > > > > Sure, but REPLACE replaces only the accessible portion of the buffert, > > not all of it. > > Then we should tighten the check even further. Instead of just adding > > if (!NILP (visit)) > > we should additionally check that BEG==BEGV and Z==ZV: > > if (!NILP (visit) && BEG == BEGV && Z == ZV) To this I agree: the condition means that the previous buffer contents is discarded, and likewise its relation to the original file, and the buffer will from now on visit the new file, originally having the exact contents of that new file. In that specific case, indeed there's no sense in any super-session warnings. > Tho, maybe the `BEG == BEGV && Z == ZV` check should be performed in the > above quoted sanity check, because I think using a non-nil VISIT within > a narrowed buffer goes against the intention of VISIT. I'd be reluctant to make such a change: who knows which package out there uses this unintentional feature? From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 27 23:14:55 2025 Received: (at 78866-done) by debbugs.gnu.org; 28 Jun 2025 03:14:55 +0000 Received: from localhost ([127.0.0.1]:45380 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVM1m-00031u-PE for submit@debbugs.gnu.org; Fri, 27 Jun 2025 23:14:55 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:46857) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uVM1k-000310-Fo for 78866-done@debbugs.gnu.org; Fri, 27 Jun 2025 23:14:52 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 17BB280B15; Fri, 27 Jun 2025 23:14:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1751080486; bh=UFafQIXK9C6lnWkA1fxUm5J6I/nd4PGHLYlD9CcmRVE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=JC0k/eD29xAWmXu9RvbdtIVaOUf/vC/l7eFuKqgDhJgw0l/rrX0ak3lbKIJznLI3c tMt7sCIFHYqydjpEWhSUeiIgI9+2ixuANwYORnp8TYDvn3lrkWfdDS1jHXIFviMgFN WSaAhca8HbdnZ/osmgsgDlS+3TDdU1AqDDSfV8BBJXYq8FHVPIWbYFmY1Yw5Yr16sA ouh6u6EYWa3WNi+toolUbfx1zMXDNIEz1W9OiyLpVfinXiJUucqpEb8UyfATk935G1 qQn3IByknEPLQFgUcg0jBtTAucblSKwMr6+Z0k6HxqYy0EKTU0pO3KdmcuMmjyKIQR 7ak2xIxjgfGpg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0DB59807B7; Fri, 27 Jun 2025 23:14:46 -0400 (EDT) Received: from pastel (unknown [104.247.225.139]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D73001201BF; Fri, 27 Jun 2025 23:14:45 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#78866: [PATCH] (Finsert_file_contents): Refine commit d07af40d8826 In-Reply-To: <86jz4ybg4s.fsf@gnu.org> Message-ID: References: <86bjqadg2q.fsf@gnu.org> <86v7oibot3.fsf@gnu.org> <86jz4ybg4s.fsf@gnu.org> Date: Fri, 27 Jun 2025 23:14:45 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.312 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78866-done Cc: 78866-done@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: -3.3 (---) >> we should additionally check that BEG==BEGV and Z==ZV: >> >> if (!NILP (visit) && BEG == BEGV && Z == ZV) > > To this I agree: the condition means that the previous buffer contents > is discarded, and likewise its relation to the original file, and the > buffer will from now on visit the new file, originally having the > exact contents of that new file. In that specific case, indeed > there's no sense in any super-session warnings. Thanks, pushed. >> Tho, maybe the `BEG == BEGV && Z == ZV` check should be performed in the >> above quoted sanity check, because I think using a non-nil VISIT within >> a narrowed buffer goes against the intention of VISIT. > I'd be reluctant to make such a change: who knows which package out > there uses this unintentional feature? Fair enough, closing, Stefan From unknown Sun Jul 27 05:59:56 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, 26 Jul 2025 11:24:11 +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