From unknown Tue Jun 17 01:48:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil Resent-From: Jimmy Yuen Ho Wong Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Jun 2025 16:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 78777 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 78777@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.174974753627773 (code B ref -1); Thu, 12 Jun 2025 16:59:01 +0000 Received: (at submit) by debbugs.gnu.org; 12 Jun 2025 16:58:56 +0000 Received: from localhost ([127.0.0.1]:59919 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPlGR-0007Ds-RR for submit@debbugs.gnu.org; Thu, 12 Jun 2025 12:58:56 -0400 Received: from lists.gnu.org ([2001:470:142::17]:34988) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPlGP-0007DY-Iy for submit@debbugs.gnu.org; Thu, 12 Jun 2025 12:58:54 -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 1uPlGF-00062c-AN for bug-gnu-emacs@gnu.org; Thu, 12 Jun 2025 12:58:43 -0400 Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1uPlGD-00037N-0E for bug-gnu-emacs@gnu.org; Thu, 12 Jun 2025 12:58:42 -0400 Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-450cb2ddd46so6868635e9.2 for ; Thu, 12 Jun 2025 09:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749747516; x=1750352316; darn=gnu.org; h=mime-version:message-id:date:subject:to:from:from:to:cc:subject :date:message-id:reply-to; bh=6oO3Uh1wtDh+2brdY2BS9gstlMcLv3xMmA3EYi/zvJs=; b=JqDk1nZmPInquTZ+DsDKETgwVau/K5Fm91ItdAJszrx3sjN3s2pztoMcyC+amgwFfc LPgSJztDZBH5bslF1c6ZLJmZbx/4rOFUofbAv1D5Ov8POB8KIb04wczYKNc/Jjh0rTH4 hAz1kp32dv8KQcqjHJehKDuDy/rgkaiJYMxupNhrIceWtUdjQT/sAg5JQlZi9zbFje3L kQfSj4ed3BtDupxmG50knIOYhxBr0K9sKAJZaGuNtc5ucUBTLrTNb8GCQ+EnK9OjLm83 Z4LoUU5566z7mU3kapaJ6sIJeJ0NgVbX2aQzk1E/VrLVj8Imzu8iRqZx1OE+roQq0KYz PC4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749747516; x=1750352316; h=mime-version:message-id:date:subject:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=6oO3Uh1wtDh+2brdY2BS9gstlMcLv3xMmA3EYi/zvJs=; b=GssH75/irPs+883cq9178M8gLtjjrOizpT39+m8dhguwPfMzICbHIJ8bgjx+gb0vz1 cT8XfrqZLFd0uOQM3ax0Wai/OEzGILAsQrYCCCzkg9qHkOk3CRhpJViR+cpO5AVkYLp1 ryNi7H7A1T+UICTt/fiLQoLnpKXHXA8q9BgvHHTU81UtO0T5OMrEIEIv2zc59xeQzLMX qLlJ29b8U813YXAnSSj3qjzTlmmaZxl/KhSdxOiOwanS53ekbItdOLw3VaCSqTyf+Jf8 AOQPyQuOamWnzzU/j9D/1OSTz3ihAdvKSMWvmf55xeEBZ1HFWQc5voCgf+jFngMn/CkX EBKQ== X-Gm-Message-State: AOJu0Yxe2pGgv8Y0kJOkGWyxvFA5afSI1HTn7mtBy9y3VyQIdddtiMbr NSI3Tioh6K579iIbGrQyClL6AxT3JApKU8BqvuGnjQWfIZv8qZqfjhMoVOYSeWJk X-Gm-Gg: ASbGncvpyA+qRjG7d/WYWszkvmmnyIHt2yUWxPID4WP2resunHO0SFQ5+PMUy2XWym6 pme4Rzl1K+QmiRmv+38L029Q1DojQoTwyEw/wJLlOQB7LRy3OizPZeRaU30ePrL0VG3ObkUDtLI Gb0OqLum37sgb9rKgwix8LvLR7dqJktaSMQAPLMJqrOOEEQ2l5iE8dLZxcSrN4Rlbt4ikLBT0U7 RkZdQrVdYSlNRL+R5IzbWzShT2BpqLZjlYtAjHz6UunFXbDSNT1B2+IrGOBQ+0lb7jiV9tuEBMX XdTZmK6IciY70u9aU9iw/2fm3S3dEgUB3Riob04zij3JTY1r1XcA5o5c54mVA3viAfQ5h7Jf7Fh v6Sod7QdH5piVhU2tpMJGR6Nc X-Google-Smtp-Source: AGHT+IFNszOt55Jl3ZLLE+bpO9FfISWn6XgAf6k3Kq62iISHXDZNS0V91RXIuOMj3Y+I+D19ONkfXw== X-Received: by 2002:a05:600c:1d07:b0:442:c993:6f94 with SMTP id 5b1f17b1804b1-4532487a5dcmr84119715e9.12.1749747516286; Thu, 12 Jun 2025 09:58:36 -0700 (PDT) Received: from MacBookPro.localdomain ([2a01:4b00:89a0:2400:3954:b164:2078:f5f8]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4532e22460bsm27312955e9.6.2025.06.12.09.58.35 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 12 Jun 2025 09:58:35 -0700 (PDT) From: Jimmy Yuen Ho Wong Date: Thu, 12 Jun 2025 17:58:34 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::335; envelope-from=wyuenho@gmail.com; helo=mail-wm1-x335.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) 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: -0.0 (/) When investigating https://github.com/emacs-lsp/lsp-mode/issues/4782 and https://github.com/purcell/emacs-reformatter/issues/63, I've discovered the following bug in insert-file-contents. Reproduction: 1. echo "hello world" > ~/test.txt 2. emacs -q ~/test.txt 3. M-x eval-expression RET (add-hook 'after-change-functions (lambda (&rest _) (message "buffer-file-name: %s, current-buffer: %s" (buffer-file-name) (current-buffer))) nil t) RET 4. Type something into the buffer 5. M-x eval-expression RET (insert-file-contents (buffer-file-name) nil nil nil t) RET 6. Switch to the *Messages* buffer and observe the buffer file name is nil. Expectation: insert-file-contents should not set buffer-file-name to nil From unknown Tue Jun 17 01:48:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Jun 2025 18:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78777 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Jimmy Yuen Ho Wong Cc: 78777@debbugs.gnu.org Received: via spool by 78777-submit@debbugs.gnu.org id=B78777.174975239816641 (code B ref 78777); Thu, 12 Jun 2025 18:20:02 +0000 Received: (at 78777) by debbugs.gnu.org; 12 Jun 2025 18:19:58 +0000 Received: from localhost ([127.0.0.1]:60279 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPmWr-0004KL-ME for submit@debbugs.gnu.org; Thu, 12 Jun 2025 14:19:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42324) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPmWp-0004Jv-9y for 78777@debbugs.gnu.org; Thu, 12 Jun 2025 14:19:55 -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 1uPmWj-0005G1-Sz; Thu, 12 Jun 2025 14:19:49 -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=yc9+F9R5/8aftnRN8R/TqpGVFWYSLhhQJLu/etM60Z8=; b=khBi3OHQlpr/ YP+Vmm5sQGtDc1q5u2yYQ2i9lHLqwcq5PtShaxvaOW8eYB9iAyWqv4VDOOMowXvCdI/u2MYcN7nJx RH8Z4RdGvIUtTSviyblLfX1zDJoXF5joTr59H2JT1wQJafPKiQ97gZAnQEy08e5p8RvCKw61SQ98j MXT1J05COx3S60YmT1Wd+KSs4Q75mZ7Z5u1Zqio09bS5NB2OvmFxOnGOJP7AXu43hfRjL575iHits guSZu4JKtRwfj0KJsReIawzRR7f+Bfa5XrrilwwrZgSVMG86BTf1qjmgy0kBdL3TGLlKiZL4GoUSs YVu+R8Zi7pNn0Oz7f8IBew==; Date: Thu, 12 Jun 2025 21:19:47 +0300 Message-Id: <8634c4g6v0.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Jimmy Yuen Ho Wong on Thu, 12 Jun 2025 17:58:34 +0100) References: X-Spam-Score: -2.3 (--) 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: Jimmy Yuen Ho Wong > Date: Thu, 12 Jun 2025 17:58:34 +0100 > > > When investigating https://github.com/emacs-lsp/lsp-mode/issues/4782 and > https://github.com/purcell/emacs-reformatter/issues/63, I've discovered > the following bug in insert-file-contents. > > Reproduction: > > 1. echo "hello world" > ~/test.txt > 2. emacs -q ~/test.txt > 3. M-x eval-expression RET (add-hook 'after-change-functions (lambda (&rest _) (message "buffer-file-name: %s, current-buffer: %s" (buffer-file-name) (current-buffer))) nil t) RET > 4. Type something into the buffer > 5. M-x eval-expression RET (insert-file-contents (buffer-file-name) nil nil nil t) RET > 6. Switch to the *Messages* buffer and observe the buffer file name is nil. > > Expectation: > > insert-file-contents should not set buffer-file-name to nil I don't think it does. (buffer-file-name) returns nil when the call is evaluated in the minibuffer, and I thin that's what you see. After performing the above recipe the buffer-filename of the buffer that visits test.txt remains to be "test.txt", at least in my testing. So the only evidence that it's set to nil are the messages logged in *Messages*, and they are about a different buffer. From unknown Tue Jun 17 01:48:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil Resent-From: Jimmy Yuen Ho Wong Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Jun 2025 19:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78777 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78777@debbugs.gnu.org Received: via spool by 78777-submit@debbugs.gnu.org id=B78777.17497569183978 (code B ref 78777); Thu, 12 Jun 2025 19:36:01 +0000 Received: (at 78777) by debbugs.gnu.org; 12 Jun 2025 19:35:18 +0000 Received: from localhost ([127.0.0.1]:60692 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPnhl-00011z-B2 for submit@debbugs.gnu.org; Thu, 12 Jun 2025 15:35:17 -0400 Received: from mail-pl1-x634.google.com ([2607:f8b0:4864:20::634]:45498) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uPnhg-0000x4-Vz for 78777@debbugs.gnu.org; Thu, 12 Jun 2025 15:35:14 -0400 Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-2360ff7ac1bso10865565ad.3 for <78777@debbugs.gnu.org>; Thu, 12 Jun 2025 12:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749756907; x=1750361707; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=eJZ8DvYdi4/ZROHPVN/gBS1tZmA8V2q9ViGvwxJJMj4=; b=bMT+GJqJcrCdNDr+v7tUp8yBFNX3ZFvUogeVU0Op9HOYxs5LERBEJX4GzByTAEmPgJ JHESqiZe1TYx6hpmQZLNfOsmlsHICWNM69kylnZn8TTEssyDsooYTqHJdfRoXo5nMDJM ssqYxmzli0QLZzuMRRHYz1o6RqBtrPUQ64GsJObL2ICO6poY+Ar2cDxhStcHvksdyooJ rIhpHKvuD2GPQ6gnYTjqTYOjBXw3nKrJbIvvhpdQMLT5BQeavWcSGwrLCDA/hZurYTom wwk4XaKRVyxJQdyF1pDsIqznSbbNglYmwJ7+y0ELn06Pfkid5zUdHwK6PEdv/ve1K+1z 4q4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749756907; x=1750361707; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=eJZ8DvYdi4/ZROHPVN/gBS1tZmA8V2q9ViGvwxJJMj4=; b=kVVVk6fEWlqF/fydb7GS2yEBVk1Jh81a2v2/LHDtY8zUAqWSn16NMROsX1ZSYTffe9 OB4CWJpAtR/2ioJloIgvPzPF+QZg/gwCi8OdwTz9gQcw41FDOtyN8+WoilIacObSQ/cy A6/JvGItNKmyjL/Ud20gFlEjoVEXQKiRunJVIiWYkiCc4bkkmkf1GSVBJ2mb1xXkBMpq Ov89lk9sanV+sI+VbdWRGy5YIZ62tjF68T71rgycjEfCt6LJcf3F+YLgW26tCnwfj7Hb yWS919iwPuPZZp6YrE4rF7eAZTAbXdWepq53+CRuIYrySHGD3BfVUnzaGEO5TUAEFFvI pVbQ== X-Gm-Message-State: AOJu0Yw4fuhfg7tTRBdRYMzCDakCcNW0PpVmlWWdpl0qj564eg72ru8Z Rm99PgAT5U4SmdRFx42u61LnqY8efJsYbeqRQOIyp0DdHjFBGjbJVhBxBO1haWPrXY0y05kPJMf JI/+7SQMoKlEiGMTpekeoT1gdVM9OCy4= X-Gm-Gg: ASbGnctHpaTLtOit8woH6NmI8QmTcMqixCFV5/q+FH4U+keb9EOaHRtYyJ3xW6omdHo 6PmXRIKXmhSE8kTzX+pfmrP9/5XNLmh3Wx/dM4OyTg9egDRchUaeHsviFlFolmLLtk9z1cbRF4Z QITo9iy3eIm8Vkx/qgMkYm9LAvNEIDRxUuvceaVUsTG2L0qDaCBG57o8ozr3V5wVr8yHrWNxSpv eDyHw== X-Google-Smtp-Source: AGHT+IGixn3SGRLAAD1etB/HHVkTQ/NpW48V1+CFUAxyNfjCXstAzb2fMKQECgmPIbylQucUUIGbsXLo0hdB+6mbvgA= X-Received: by 2002:a17:90b:544f:b0:313:27e5:7ff1 with SMTP id 98e67ed59e1d1-313d9c60fa0mr512740a91.1.1749756906571; Thu, 12 Jun 2025 12:35:06 -0700 (PDT) MIME-Version: 1.0 References: <8634c4g6v0.fsf@gnu.org> In-Reply-To: <8634c4g6v0.fsf@gnu.org> From: Jimmy Yuen Ho Wong Date: Thu, 12 Jun 2025 20:34:30 +0100 X-Gm-Features: AX0GCFsnGnSPG7EZdBifCzkM8VbRoTGM-a_bMjFUXKPtCeJzKSnOoUE6NdYeMMY Message-ID: Content-Type: multipart/alternative; boundary="000000000000dc0dbc06376506be" X-Spam-Score: 0.0 (/) 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 (-) --000000000000dc0dbc06376506be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 12, 2025 at 7:19=E2=80=AFPM Eli Zaretskii wrote: > > From: Jimmy Yuen Ho Wong > > Date: Thu, 12 Jun 2025 17:58:34 +0100 > > > > > > When investigating https://github.com/emacs-lsp/lsp-mode/issues/4782 an= d > > https://github.com/purcell/emacs-reformatter/issues/63, I've discovered > > the following bug in insert-file-contents. > > > > Reproduction: > > > > 1. echo "hello world" > ~/test.txt > > 2. emacs -q ~/test.txt > > 3. M-x eval-expression RET (add-hook 'after-change-functions (lambda > (&rest _) (message "buffer-file-name: %s, current-buffer: %s" > (buffer-file-name) (current-buffer))) nil t) RET > > 4. Type something into the buffer > > 5. M-x eval-expression RET (insert-file-contents (buffer-file-name) nil > nil nil t) RET > > 6. Switch to the *Messages* buffer and observe the buffer file name is > nil. > > > > Expectation: > > > > insert-file-contents should not set buffer-file-name to nil > > I don't think it does. (buffer-file-name) returns nil when the call > is evaluated in the minibuffer, and I thin that's what you see. After > performing the above recipe the buffer-filename of the buffer that > visits test.txt remains to be "test.txt", at least in my testing. So > the only evidence that it's set to nil are the messages logged in > *Messages*, and they are about a different buffer. > When a lisp expression is evaluated in the minibuffer, the current buffer is the file buffer, not the minibuffer. You can easily verify this with M-x eval-expression RET (current-buffer) RET. The crux of the matter is the lambda added to after-change-function. `insert-file-contents` calls `signals_after_change` (fileio.c line 5007 on master), which will run the after-change-functions. It is at this moment the buffer-file-name is nil. In addition, the following will NOT result in insert-file-contents temporarily setting the buffer-file-name of the current buffer to nil: (let ((coding-system-for-read 'no-conversion) (coding-system-for-write 'no-conversion)) (insert-file-contents (buffer-file-name) nil nil nil t)) Which suggests some of the code conversion logic in the C function is erroneously setting the current buffer's file-name to nil, and then running the after-change-functions before resetting it. --000000000000dc0dbc06376506be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Jun 12, 2025 a= t 7:19=E2=80=AFPM Eli Zaretskii <eliz@gn= u.org> wrote:
> Fr= om: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Thu, 12 Jun 2025 17:58:34 +0100
>
>
> When investigating https://github.com/emacs-ls= p/lsp-mode/issues/4782 and
> https://github.com/purcell/emacs-reformat= ter/issues/63, I've discovered
> the following bug in insert-file-contents.
>
> Reproduction:
>
> 1. echo "hello world" > ~/test.txt
> 2. emacs -q ~/test.txt
> 3. M-x eval-expression RET (add-hook 'after-change-functions (lamb= da (&rest _) (message "buffer-file-name: %s, current-buffer: %s&qu= ot; (buffer-file-name) (current-buffer))) nil t) RET
> 4. Type something into the buffer
> 5. M-x eval-expression RET (insert-file-contents (buffer-file-name) ni= l nil nil t) RET
> 6. Switch to the *Messages* buffer and observe the buffer file name is= nil.
>
> Expectation:
>
> insert-file-contents should not set buffer-file-name to nil

I don't think it does.=C2=A0 (buffer-file-name) returns nil when the ca= ll
is evaluated in the minibuffer, and I thin that's what you see.=C2=A0 A= fter
performing the above recipe the buffer-filename of the buffer that
visits test.txt remains to be "test.txt", at least in my testing.= =C2=A0 So
the only evidence that it's set to nil are the messages logged in
*Messages*, and they are about a different buffer.
When a lisp expression is evaluated in the minibuffer, the curr= ent buffer is the file buffer, not the minibuffer. You can easily verify th= is with M-x eval-expression RET (current-buffer)=C2=A0 RET.

The crux= of the matter is the lambda added to after-change-function. `insert-file-c= ontents` calls `signals_after_change` (fileio.c line 5007 on master), which= will run the after-change-functions. It is at this moment the buffer-file-= name is nil.

In addition, the following will NOT result in insert-fi= le-contents temporarily setting the buffer-file-name of the current buffer = to nil:

(let ((coding-system-for-read 'no-conversion)
= =C2=A0 =C2=A0 =C2=A0 (coding-system-for-write 'no-conversion))
=C2= =A0 (insert-file-contents (buffer-file-name) nil nil nil t))

Which s= uggests some of the code conversion logic in the C function is erroneously= =C2=A0setting the current buffer's file-name to nil, and then running t= he after-change-functions before resetting it.
--000000000000dc0dbc06376506be-- From unknown Tue Jun 17 01:48:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 14:52:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78777 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Jimmy Yuen Ho Wong Cc: 78777@debbugs.gnu.org Received: via spool by 78777-submit@debbugs.gnu.org id=B78777.17499126902382 (code B ref 78777); Sat, 14 Jun 2025 14:52:05 +0000 Received: (at 78777) by debbugs.gnu.org; 14 Jun 2025 14:51:30 +0000 Received: from localhost ([127.0.0.1]:40089 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQSEE-0000cL-Bu for submit@debbugs.gnu.org; Sat, 14 Jun 2025 10:51:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60594) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQSEC-0000c5-Tf for 78777@debbugs.gnu.org; Sat, 14 Jun 2025 10:51:29 -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 1uQSE7-0002TE-Ie; Sat, 14 Jun 2025 10:51:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=mFjjssncGHDi6l267jF9IeEvGVmPooNk7yZhp80GkX0=; b=iuGDo98JbDFdtaXjWhwl h47DCIMGvRGq9mVX3bgjkt6qBNhE26XXrlDx8rSYpO+4a3Tba2YRwfRKNmhLmNtsHNoSU4cdbuEzc PINKGGmMaz5o42uXF/qLIa0i1/gncrZZvjOUuBkKSowNL2YOmx3Zg4jqt3xwoy6tbL9F5a+sgGse2 4SGlOsJimidnu0XCXqV7mY5qaOIuuzo0drvVqJB2pEGjAaDq0WrgLV0vnISPRvyMIYxJoLKhZ0ljr lr6iZTJN+n6nKMSCkVnCUqZf2/oBBEM2ErRc5MO1jtIUoPQ5eaLSOsFoIFfutD3S3r//IMRHB0n/t YE/Rc7Eh84fEig==; Date: Sat, 14 Jun 2025 17:51:22 +0300 Message-Id: <86y0tuqsut.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Jimmy Yuen Ho Wong on Thu, 12 Jun 2025 20:34:30 +0100) References: <8634c4g6v0.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) 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: Jimmy Yuen Ho Wong > Date: Thu, 12 Jun 2025 20:34:30 +0100 > Cc: 78777@debbugs.gnu.org > > On Thu, Jun 12, 2025 at 7:19 PM Eli Zaretskii wrote: > > > From: Jimmy Yuen Ho Wong > > Date: Thu, 12 Jun 2025 17:58:34 +0100 > > > > > > When investigating https://github.com/emacs-lsp/lsp-mode/issues/4782 and > > https://github.com/purcell/emacs-reformatter/issues/63, I've discovered > > the following bug in insert-file-contents. > > > > Reproduction: > > > > 1. echo "hello world" > ~/test.txt > > 2. emacs -q ~/test.txt > > 3. M-x eval-expression RET (add-hook 'after-change-functions (lambda (&rest _) (message > "buffer-file-name: %s, current-buffer: %s" (buffer-file-name) (current-buffer))) nil t) RET > > 4. Type something into the buffer > > 5. M-x eval-expression RET (insert-file-contents (buffer-file-name) nil nil nil t) RET > > 6. Switch to the *Messages* buffer and observe the buffer file name is nil. > > > > Expectation: > > > > insert-file-contents should not set buffer-file-name to nil > > I don't think it does. (buffer-file-name) returns nil when the call > is evaluated in the minibuffer, and I thin that's what you see. After > performing the above recipe the buffer-filename of the buffer that > visits test.txt remains to be "test.txt", at least in my testing. So > the only evidence that it's set to nil are the messages logged in > *Messages*, and they are about a different buffer. > > When a lisp expression is evaluated in the minibuffer, the current buffer is the file buffer, not the minibuffer. > You can easily verify this with M-x eval-expression RET (current-buffer) RET. > > The crux of the matter is the lambda added to after-change-function. `insert-file-contents` calls > `signals_after_change` (fileio.c line 5007 on master), which will run the after-change-functions. It is at this > moment the buffer-file-name is nil. > > In addition, the following will NOT result in insert-file-contents temporarily setting the buffer-file-name of the > current buffer to nil: > > (let ((coding-system-for-read 'no-conversion) > (coding-system-for-write 'no-conversion)) > (insert-file-contents (buffer-file-name) nil nil nil t)) > > Which suggests some of the code conversion logic in the C function is erroneously setting the current > buffer's file-name to nil, and then running the after-change-functions before resetting it. I think your after-change-function is called not due to insert-file-contents inserting the text from the file, but from the functions that decode the file's text. To see if this is true, make your after-change-function show the name of the current buffer. If I'm right, you will see something like " *code conversion works" as the name of the buffer, in which case indeed buffer-filename is expected to be nil, and I don't see a bug here. From unknown Tue Jun 17 01:48:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil Resent-From: Jimmy Yuen Ho Wong Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Jun 2025 14:46:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78777 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78777@debbugs.gnu.org Received: via spool by 78777-submit@debbugs.gnu.org id=B78777.174999875124906 (code B ref 78777); Sun, 15 Jun 2025 14:46:06 +0000 Received: (at 78777) by debbugs.gnu.org; 15 Jun 2025 14:45:51 +0000 Received: from localhost ([127.0.0.1]:58360 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQocG-0006TU-Dp for submit@debbugs.gnu.org; Sun, 15 Jun 2025 10:45:50 -0400 Received: from mail-pj1-x102d.google.com ([2607:f8b0:4864:20::102d]:53493) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uQocC-0006SA-5b for 78777@debbugs.gnu.org; Sun, 15 Jun 2025 10:45:45 -0400 Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-311a6236effso3053848a91.2 for <78777@debbugs.gnu.org>; Sun, 15 Jun 2025 07:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749998738; x=1750603538; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=X6tVdVfxSydgdM4f/igaGl0qVNgO512xbYGg7emeyXI=; b=fdShh+gWvzuEzXKSSPTpN4zjMFtW1Jtlv4G0D/196GDUsMfmhjgYLMfIE1CjGlV3+f 8hyN0fDrk/yy/bnZpHZtuC7tIuVMoeVoTq1EaDj0f1QOx9jfay91utdh8CVtyvBf0ril tOs9napRsbLySYcjBlYS9xtequTN1k05qzVMWPUZWDfBmnwPFSKrDZBhBCNU+vv6OZNU b6qRJb+KzAf0/bylzVa4KidDDioIlT8yRxEtOd3ZBE5PnrlWQ5QfLljh8FmxILo7jPk1 7uXjgj7E6yHhbZJTwDm4Pqlf6nPX9Y/S4E2C377TzFkFC2SIXe0nGtl5om7Gvjw36AoV iHvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749998738; x=1750603538; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=X6tVdVfxSydgdM4f/igaGl0qVNgO512xbYGg7emeyXI=; b=XQp6oq0ylyqv04CBQXvMAeTOzKSBlLRnXPFgy/YLGs/XT0c4Ph6lZH0bgwlsfxSNfp x7jM+4XScgMlcXhWGfiIZUVC3vftqJDJb8Ar707nzLQqXWgesYvksPqkzkN1dkT0Z3gs xSM6P9Azm34a3SrqiOJWeBahmsborv9c61yl3fEomVvev8rHN3ywRv2cWpT0X6LMKPj4 q6rwyTdlWQ5tfFjSvEkKq2riP5jO+nT4CBt5hf14sGFlhxeIPNURVky4+2Ciz2+0QpY0 7MfSYKui6ycFgn2Rmc3p0MWGUvZlho5Qt8JcOZf3nFcqKfor6iVEmHHJVeWHsLUCnWED B5NA== X-Gm-Message-State: AOJu0YzEkYpt1qltWZOcXTw8BY9N9IPsU00BP9KFvIEUQ8vOk4kdR6dX UGIdWMbLePeu7t1KNrA7eVn+3dUhk3ojtyp/fHXOHQiVxmC5S4HbZfsxtAZW41A1iBDPFRzQHVd u5Lh5/18RYVyl5WO7pg3poUDxlKH5p90= X-Gm-Gg: ASbGncv6KpPGb869il38Qcus1glhAlw/j6ZWGhbc7mjGEeNp/KiQgIqYWbAOu/UGYgb gEqPv89o2VVLQEwOp7b/jHGRL2+ydzcwmky7YMhyoP7O6uw+99mWOpiOCgPoEJFgp4rQWcmaZGo wAiE/7J5VZ+UYQqYrGmd2nv6PLX0eWg3PjGhfXY9U9kH57wEz7xqbH4j1vhXVl+17NVTA5xDzB6 Pd6RvpwYF83kUA= X-Google-Smtp-Source: AGHT+IEP2NyOYXf8MIlh66W1kb3t8aatpq6TNQrdO1O47muj2ugaSbqr+hkxiBrvn1/LCmc29UR8MJ+V2pRzR7kUTmo= X-Received: by 2002:a17:90b:1cc3:b0:311:d05c:936 with SMTP id 98e67ed59e1d1-313f1daa6a7mr11166319a91.17.1749998737899; Sun, 15 Jun 2025 07:45:37 -0700 (PDT) MIME-Version: 1.0 References: <8634c4g6v0.fsf@gnu.org> <86y0tuqsut.fsf@gnu.org> In-Reply-To: <86y0tuqsut.fsf@gnu.org> From: Jimmy Yuen Ho Wong Date: Sun, 15 Jun 2025 15:45:02 +0100 X-Gm-Features: AX0GCFuRQSbY75kP85g0DZOZLAyJy69SsU2a3Ea-rfnkHdD2EY-oKfYGLE-D8mM Message-ID: Content-Type: multipart/alternative; boundary="00000000000021460506379d55dd" X-Spam-Score: 0.0 (/) 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 (-) --00000000000021460506379d55dd Content-Type: text/plain; charset="UTF-8" > I think your after-change-function is called not due to > insert-file-contents inserting the text from the file, but from the > functions that decode the file's text. To see if this is true, make > your after-change-function show the name of the current buffer. If > I'm right, you will see something like " *code conversion works" as > the name of the buffer, in which case indeed buffer-filename is > expected to be nil, and I don't see a bug here. > I have suspected the same as the only call to set a buffer's name to nil is found in the implementation of insert-file-contents near the code conversion buffer, but that's a red herring. As you can see from my report, the after-change-function does contain a call to (current-buffer), and the message prints out the file buffer's name correctly. Curiously, if you save the file between step 4 and 5 from my reproduction instruction, the buffer-file-name is printed correctly. Hope this helps. --00000000000021460506379d55dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think you= r after-change-function is called not due to
insert-file-contents inserting the text from the file, but from the
functions that decode the file's text.=C2=A0 To see if this is true, ma= ke
your after-change-function show the name of the current buffer.=C2=A0 If I'm right, you will see something like " *code conversion works&qu= ot; as
the name of the buffer, in which case indeed buffer-filename is
expected to be nil, and I don't see a bug here.
=C2=A0I have suspected the same as the only call to set a buff= er's name to nil is found in the implementation of insert-file-contents= near the code conversion buffer, but that's a red herring. As you can = see from my report, the after-change-function does contain a call to (curre= nt-buffer), and the message prints out the file buffer's name correctly= .

Curiously, if you save the file between step 4 and 5 from my repro= duction instruction, the buffer-file-name is printed correctly.
<= br>
Hope this=C2=A0helps.
--00000000000021460506379d55dd-- From unknown Tue Jun 17 01:48:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Jun 2025 15:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78777 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Jimmy Yuen Ho Wong Cc: 78777@debbugs.gnu.org Received: via spool by 78777-submit@debbugs.gnu.org id=B78777.174999962929675 (code B ref 78777); Sun, 15 Jun 2025 15:01:02 +0000 Received: (at 78777) by debbugs.gnu.org; 15 Jun 2025 15:00:29 +0000 Received: from localhost ([127.0.0.1]:58394 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQoqQ-0007hv-Fd for submit@debbugs.gnu.org; Sun, 15 Jun 2025 11:00:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46446) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQoqL-0007fL-D2 for 78777@debbugs.gnu.org; Sun, 15 Jun 2025 11:00:24 -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 1uQoqF-0003gj-GQ; Sun, 15 Jun 2025 11:00:15 -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=d2fHmMFnhhL3lOR2t0VdnglBIk4sQCjXbBJTaM9iDSw=; b=Z4g8H7W4MAVw ZVRDmOS7T/nYuJAftKytxy3yJ/R52eGOC1efkqfiWbx5lrw9dbXyKJBk7JaC9BWeW41eUOe+p60k5 iGdVHeq54sSsOjqul7j79j0JYGK3be81QkaWBvOxVOfwv1LDxMXYAEBBs0DE+BOTkT7oAwRSmHZbv xsmNjC94stZAdn2CNvxNSHkKm/23esZ3s5i16knHHcleF3skbbnIY06TTOVaLAIL44C5TxPj5WvBh IzSrvlwQ5rzpTg2CiU2nHNAhUOLlDFh2if25HUqacORABrL8qwDyi1IEGep5z1Omwvn1TZjOnNeXp KiDJykYYHW+DikpdqaKYBg==; Date: Sun, 15 Jun 2025 18:00:12 +0300 Message-Id: <86tt4hoxs3.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Jimmy Yuen Ho Wong on Sun, 15 Jun 2025 15:45:02 +0100) References: <8634c4g6v0.fsf@gnu.org> <86y0tuqsut.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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: Jimmy Yuen Ho Wong > Date: Sun, 15 Jun 2025 15:45:02 +0100 > Cc: 78777@debbugs.gnu.org > > I think your after-change-function is called not due to > insert-file-contents inserting the text from the file, but from the > functions that decode the file's text. To see if this is true, make > your after-change-function show the name of the current buffer. If > I'm right, you will see something like " *code conversion works" as > the name of the buffer, in which case indeed buffer-filename is > expected to be nil, and I don't see a bug here. > > I have suspected the same as the only call to set a buffer's name to nil is found in the implementation of > insert-file-contents near the code conversion buffer, but that's a red herring. As you can see from my > report, the after-change-function does contain a call to (current-buffer), and the message prints out the file > buffer's name correctly. That's not what I see. The only call to after-change-functions that insert-file-contents does is not done in your recipe: if I set a breakpoint there, it is never hit. So I have no doubt that what you see is an unrelated call to after-change-functions. The evidence that current-buffer returns the buffer name you expect is not enough: the actual current buffer can be different, and I saw it in GDB. So, given what I see under a debugger, there's no bug here. Why did you think insert-file-contents should at all call after-change-functions in this scenario? From unknown Tue Jun 17 01:48:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil Resent-From: Jimmy Yuen Ho Wong Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Jun 2025 15:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78777 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78777@debbugs.gnu.org Received: via spool by 78777-submit@debbugs.gnu.org id=B78777.17500007093676 (code B ref 78777); Sun, 15 Jun 2025 15:19:02 +0000 Received: (at 78777) by debbugs.gnu.org; 15 Jun 2025 15:18:29 +0000 Received: from localhost ([127.0.0.1]:58580 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQp7s-0000xA-6N for submit@debbugs.gnu.org; Sun, 15 Jun 2025 11:18:28 -0400 Received: from mail-pj1-x102c.google.com ([2607:f8b0:4864:20::102c]:53367) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uQp7p-0000wZ-P7 for 78777@debbugs.gnu.org; Sun, 15 Jun 2025 11:18:26 -0400 Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-311a6236effso3065307a91.2 for <78777@debbugs.gnu.org>; Sun, 15 Jun 2025 08:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750000699; x=1750605499; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9o1ybaWxTqGMJn1x7AsYJV8RUljz2gp1L14Hzrro4IY=; b=jmQppMDoHl5QHJhqTTYScBiyO82l9/wC7QzWPSiuHSxe1AjwusSfEWehojF45/MUYq 6SJ0+pRnRt3WTS2u6iDVyBDqvNrgeSIRHkmaznp0GE3jEECLBc+ZVW5PSTjRHBJ3GK7A 8ZSGsHu4YIoYzX5qWB95CfvzLYpuO+D0HlYrzV2j943a+sGy+LmW5BMRirJ7lENg2fDL CVOvIfcnfDfSn4v+z13/jZygcWCMSPp0YCjzxbCbcCdjKUjy+aKxGrZedDkBqjHHDl0e mZTeTPVUi1eK57Gga5XpGDpuy3yVbJZiktK58pBUOHSZzFTA+bgoXg4XS5pZO5u0vLWa s+2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750000699; x=1750605499; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9o1ybaWxTqGMJn1x7AsYJV8RUljz2gp1L14Hzrro4IY=; b=P7kTBTnq6SneoFCaE9yfzW0bhDNLJjrE5KZ1tNEPNUa5vVZ59ah4c0J9xYBAun5DId fryWQ8UmJLPZPqXcU6p2mwcnXqDZPWqQeojSL9T9pX9fOLrYo7TT081NlMmSbewXvYde FOqMmm2nGx5ZgaoruJh773HjXgOVyKSHiyhmVw/8MDQNgkYyAYPqYLSj78U+AoxflkVF fTdeXMRaklpxG5Bt+mJ81pDre6DZNTIS9J5MALeO7hBTtJagvIEpRh8fdZkFX+9yGav9 h9pHgmgnp6yp14lAKjr8+JYiLGgFPv8IwbbRU92WI9pS0XgItTit3jcEIvTAAEJfr9OI m3Yg== X-Gm-Message-State: AOJu0YzPsB7LDoKE9uMsM26nB5hknAZtLliAkA49N0QJAdFXDa0kWpCb rodiht9d9aJcUAukxZ2r73sD8sVyJlbWMIXAVMityHaZ9+XlxV+fCEQjk7MY/15JsvULtypwq8L /GA+HUuoBA0SaWktYv2BL+3JLrCQEPNk= X-Gm-Gg: ASbGncs8YzxHf0pg9ghp583+DnSKNhLHN4xAwPmaNSGLMUJ9lTm7sk2VdLfQiozQWxo untQLNDMKmtBINBAqJVIZzJ3lHZCtfd4xwsipEBgRdAuqCjPqnlA3M77724MTFkU2VnSGSQdyaQ muSgosE4QBW5ZkJwm9vF8e1T5qIqurUHsmDFTstKRL9xd/HTpXJRbyDt4TNbf7flF5xvhQpp5yp oyJ X-Google-Smtp-Source: AGHT+IEApyLcmBVYpy/IX/JhUsMuO/PX0U1u3Uwgv5X74gFJLr4566L5+F3/Jz7OlXkMTBSkaJLNt4rXw6WQdppDvww= X-Received: by 2002:a17:90b:1ccc:b0:311:2f5:6b1 with SMTP id 98e67ed59e1d1-313f1deb5efmr8011647a91.22.1750000699518; Sun, 15 Jun 2025 08:18:19 -0700 (PDT) MIME-Version: 1.0 References: <8634c4g6v0.fsf@gnu.org> <86y0tuqsut.fsf@gnu.org> <86tt4hoxs3.fsf@gnu.org> In-Reply-To: <86tt4hoxs3.fsf@gnu.org> From: Jimmy Yuen Ho Wong Date: Sun, 15 Jun 2025 16:17:43 +0100 X-Gm-Features: AX0GCFsOX0OCiAXP1RfCot_06t3x5CZP7sqLceRiN5Ow85wKwdUo-czWaEhT2F0 Message-ID: Content-Type: multipart/alternative; boundary="0000000000000d36d706379dca95" X-Spam-Score: 0.0 (/) 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 (-) --0000000000000d36d706379dca95 Content-Type: text/plain; charset="UTF-8" > > That's not what I see. The only call to after-change-functions that > insert-file-contents does is not done in your recipe: if I set a > breakpoint there, it is never hit. > > So I have no doubt that what you see is an unrelated call to > after-change-functions. The evidence that current-buffer returns the > buffer name you expect is not enough: the actual current buffer can be > different, and I saw it in GDB. > > So, given what I see under a debugger, there's no bug here. > > Why did you think insert-file-contents should at all call > after-change-functions in this scenario? > I was never able to set up GDB as I'm on a Mac, so I actually am not sure if the signal_after_change call is made directly inside insert-file-contents. Looking at it again, it can't possibly be called there as that line is under the notfound label, which is only jumped to when the file descriptor is invalid. It is possible that some other Emacs internal machinery set the current buffer-file-name to nil temporarily and invoke signal_after_change after insert-file-contents has replaced the buffer content, but I have not been able to identify where. What is sure is a lone call to insert-file-contents runs the after-change-functions. --0000000000000d36d706379dca95 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's not what I see.=C2=A0 T= he only call to after-change-functions that
insert-file-contents does is not done in your recipe: if I set a
breakpoint there, it is never hit.

So I have no doubt that what you see is an unrelated call to
after-change-functions.=C2=A0 The evidence that current-buffer returns the<= br> buffer name you expect is not enough: the actual current buffer can be
different, and I saw it in GDB.

So, given what I see under a debugger, there's no bug here.

Why did you think insert-file-contents should at all call
after-change-functions in this scenario?

I was nev= er able to set up GDB as I'm on a Mac, so I actually am not sure if the= signal_after_change call is made directly inside insert-file-contents. Loo= king at it again, it can't possibly be called there as=C2=A0that line i= s under the notfound label, which is only jumped to when the file descripto= r is invalid.

It is possible that some other Emacs internal machiner= y=C2=A0set the current buffer-file-name to nil temporarily and invoke signa= l_after_change after insert-file-contents has replaced the buffer content, = but I have not been able to identify where. What is sure is a lone call to = insert-file-contents runs the after-change-functions.
--0000000000000d36d706379dca95-- From unknown Tue Jun 17 01:48:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Jun 2025 15:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78777 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Jimmy Yuen Ho Wong Cc: 78777@debbugs.gnu.org Received: via spool by 78777-submit@debbugs.gnu.org id=B78777.175000175521021 (code B ref 78777); Sun, 15 Jun 2025 15:36:02 +0000 Received: (at 78777) by debbugs.gnu.org; 15 Jun 2025 15:35:55 +0000 Received: from localhost ([127.0.0.1]:58795 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQpOl-0005Sz-Aw for submit@debbugs.gnu.org; Sun, 15 Jun 2025 11:35:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35260) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQpOi-0005Sh-Ut for 78777@debbugs.gnu.org; Sun, 15 Jun 2025 11:35:53 -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 1uQpOd-0003HU-Ix; Sun, 15 Jun 2025 11:35:47 -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=98hqSp1/Jsvj/frttWGAQKXbV4M1FEBl5rakRCTMVfQ=; b=UaxZSiprAEAX tvib/o6cmchfx3f41z661Aj1H1QR83S8CZxLGlODtB5rKq4cyeXSSGe4Zt4Np4ETpmiHdfePI0VlU NGVmy2XQ1dG2qSgLOcqcb7sbspLtYD1a4cWFRLygbJAikzXukJjhvHrWl30w5Xbp2HC7HegKeMsbg GEMrFsbwBQoTZHZIaFT97daftVBLuOppzqIPEmhzvhiOV0hos9N9MJrSs8xCYkg8vs3TXkCmQqnRu xcFTQgyzztUlF+n2LUj7k4rpWwPYAffp3p/lrEj3pEGm12mVH2w7z58F8Oksm0qqr9HbXFyllJHmX TOf4B6hWI1dyPgtsuvAakw==; Date: Sun, 15 Jun 2025 18:35:44 +0300 Message-Id: <86sek1ow4v.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Jimmy Yuen Ho Wong on Sun, 15 Jun 2025 16:17:43 +0100) References: <8634c4g6v0.fsf@gnu.org> <86y0tuqsut.fsf@gnu.org> <86tt4hoxs3.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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: Jimmy Yuen Ho Wong > Date: Sun, 15 Jun 2025 16:17:43 +0100 > Cc: 78777@debbugs.gnu.org > > That's not what I see. The only call to after-change-functions that > insert-file-contents does is not done in your recipe: if I set a > breakpoint there, it is never hit. > > So I have no doubt that what you see is an unrelated call to > after-change-functions. The evidence that current-buffer returns the > buffer name you expect is not enough: the actual current buffer can be > different, and I saw it in GDB. > > So, given what I see under a debugger, there's no bug here. > > Why did you think insert-file-contents should at all call > after-change-functions in this scenario? > > I was never able to set up GDB as I'm on a Mac, so I actually am not sure if the signal_after_change call is > made directly inside insert-file-contents. Looking at it again, it can't possibly be called there as that line is > under the notfound label, which is only jumped to when the file descriptor is invalid. > > It is possible that some other Emacs internal machinery set the current buffer-file-name to nil temporarily and > invoke signal_after_change after insert-file-contents has replaced the buffer content, but I have not been > able to identify where. What is sure is a lone call to insert-file-contents runs the after-change-functions. Yes, and that lone call is never made in your scenario. So I'm no longer sure what problem are we discussing here. From unknown Tue Jun 17 01:48:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil Resent-From: Jimmy Yuen Ho Wong Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Jun 2025 15:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78777 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78777@debbugs.gnu.org Received: via spool by 78777-submit@debbugs.gnu.org id=B78777.175000208622850 (code B ref 78777); Sun, 15 Jun 2025 15:42:02 +0000 Received: (at 78777) by debbugs.gnu.org; 15 Jun 2025 15:41:26 +0000 Received: from localhost ([127.0.0.1]:58859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQpU5-0005wT-Sx for submit@debbugs.gnu.org; Sun, 15 Jun 2025 11:41:26 -0400 Received: from mail-pj1-x1034.google.com ([2607:f8b0:4864:20::1034]:56770) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uQpU4-0005vr-GT for 78777@debbugs.gnu.org; Sun, 15 Jun 2025 11:41:24 -0400 Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-313eeb77b1fso1436076a91.1 for <78777@debbugs.gnu.org>; Sun, 15 Jun 2025 08:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750002078; x=1750606878; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DFHu8DlShvYlPh21YBz08axkFTvT1mXonZ+h2/AZy1Q=; b=JfeM5Z0e2zttmYoxcU6TyzM2SMZaaf6io0YjmObi4kAsyQAgd1PsYgcnIQNtR3OQBM dpZA6JeNh7Ow5/uKtgzMoFi7pnCSe2nNbgnaNSXLOPA+e/+XsN4DJRJCxe+vmQnmaJtS +6lSsB6CVNzqYyEN7F0zO1xLjPJedX5ttrXU40f7/25N25sTvE/RJ0MayYQ8WFFRN7Hg HCxpVS4EB+uZR9sNhA8/B7/MQOhGcfBYOTO6sy+EFOl9xRusOVE4gKy9NtesIQ7CGEaH OLN3TsNgnnXKRHubY0NBD6P6Q50oA2DIw4xBHFqVpb3d0141mFjQeu4D3a/zZIM13kDB PGLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750002078; x=1750606878; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DFHu8DlShvYlPh21YBz08axkFTvT1mXonZ+h2/AZy1Q=; b=owuGW4WNMPCiyga20uYPoE/docsrMW7/y1bV0d2AGTQRAFxkN0gDFQ9zkDgrAz2aQA PR14M6Me4cdU1Iid9JVZHJDHJ6KJX2viD2guMDjn9Z1xtCdjJD2uT74rqRQlWvUmO5xW Jnn1xP/HaIkEdzjPF8bu3s0s+/DsCXlfDDL6hZZJChCCm6UDMOa9Xd75z3rQXyfzuqlj 8PU+JJvWiHcUk2iU4mpEjs9xyi9JnkhA/jloPJDVDm9ctfj1Z3p4tythQxMWeHc3vw2S r+kS4tgLAcABGC8R4VcY8pnPGwtODxY1/a07Lx+55FoBIpeqgmJzceT/ptw6MKHwte2N sDEQ== X-Gm-Message-State: AOJu0YwLuJK59ay8bWeKu19hguLYO0rmS+zT4rtNJaa/hxuJ3snHFm20 n6p30Tc/t0Q14TGlQzemj9oQZXEoc2TjcddAbdZOqd3Pr4DzEIXxzl6H0VuZVFuEhgW5IIzzz+X Sz2xiCAFxDsfLzdt26dKXx5ZBSZ1S8xmShtF1 X-Gm-Gg: ASbGnctg/y1PHwBsMjDqUcUW5BtN9mHGUnjMZiAJw3m84cWmjoVfNVV8iy2X97QmE80 FYRGvQn+pHzhLqCScMw8U/aogEAF15mC/eQIfT8wq5dAdN0Xy7vcHxnWA8xd+CQN4cPoX2PgZ1j Lub3ueIF34KUzBE23ddqR0pFzsj15wNa/8kNxGugyZGwKHOzgzDafMJigvCT8EWpcFmBHAsFB79 Xyp6IvdYm8vbts= X-Google-Smtp-Source: AGHT+IFoogzMSllS53ckli/e8tTbV9MB7TZsdvam0SL6jmvTWnQ6ymqJK8L+fs0vpHewgFkzNFIf/WjoH+NvXRZa+Jo= X-Received: by 2002:a17:90b:3c8a:b0:311:ba32:164f with SMTP id 98e67ed59e1d1-313f1c9d429mr9880068a91.8.1750002078365; Sun, 15 Jun 2025 08:41:18 -0700 (PDT) MIME-Version: 1.0 References: <8634c4g6v0.fsf@gnu.org> <86y0tuqsut.fsf@gnu.org> <86tt4hoxs3.fsf@gnu.org> <86sek1ow4v.fsf@gnu.org> In-Reply-To: <86sek1ow4v.fsf@gnu.org> From: Jimmy Yuen Ho Wong Date: Sun, 15 Jun 2025 16:40:42 +0100 X-Gm-Features: AX0GCFu8UCxFAtV8GIAQqUZqHJ3hF_ez-VyT1GUYThpfp2CbMt1UaBIQSrzBVTY Message-ID: Content-Type: multipart/alternative; boundary="0000000000003cbe3206379e1cca" X-Spam-Score: 0.0 (/) 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 (-) --0000000000003cbe3206379e1cca Content-Type: text/plain; charset="UTF-8" > Yes, and that lone call is never made in your scenario. > > So I'm no longer sure what problem are we discussing here. > The lone call to insert-file-contents, as in step 5 of my reproduction. Calling insert-file-contents after typing in a file buffer runs the after-change-functions hooks. When these hooks are run, the current buffer's file name is seen to have been temporarily set to nil, which should not be the case. Is this clear? --0000000000003cbe3206379e1cca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, and th= at lone call is never made in your scenario.

So I'm no longer sure what problem are we discussing here.

The lone call to insert-file-contents, as in step 5= of my reproduction. Calling insert-file-contents after typing in a file bu= ffer runs the after-change-functions hooks. When these hooks are run, the c= urrent buffer's file name is seen to have been temporarily set to nil, = which should not be the case.

Is this clear?
--0000000000003cbe3206379e1cca-- From unknown Tue Jun 17 01:48:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Jun 2025 16:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78777 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Jimmy Yuen Ho Wong Cc: 78777@debbugs.gnu.org Received: via spool by 78777-submit@debbugs.gnu.org id=B78777.175000320028765 (code B ref 78777); Sun, 15 Jun 2025 16:00:02 +0000 Received: (at 78777) by debbugs.gnu.org; 15 Jun 2025 16:00:00 +0000 Received: from localhost ([127.0.0.1]:59052 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQpm0-0007TO-0N for submit@debbugs.gnu.org; Sun, 15 Jun 2025 11:59:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44072) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQply-0007T1-Bs for 78777@debbugs.gnu.org; Sun, 15 Jun 2025 11:59:54 -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 1uQplt-0005j6-1T; Sun, 15 Jun 2025 11:59:49 -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=hlySn9ad508m5i/MkjtWtgTyj0A0TlrZwiWCAhvCiDA=; b=NrL6vpx06gjH /eFsoPoE5auGhLUNGF9oX1NjVnXADDvIxzYMBm9mBHiE4KVJ86J1ppDJ5M4eAtI665XSYoQHzy4F3 JbKB6nalS/dW7Q70Wcxn1ZVMkp5azXW23xDBE6E9RfxVfekCNY5j+ikQWrd73EGP4VXpDYulSquvO T1Z0LMdKyFAtHQ6wXcZsigQv5DoLgEcX5Gjgr9ynAvFKHoqT8+j2a/wucN3itkyfZfDaR4vSLRlaV 44y4LH5hxV3OGjHDY7ulrlCvK3qcF7+hE612K20+LVsE5hiEhbn+OctuqtaCoxCnPwxAdSSl8qm5L +1aVAuY0uzQLAhDOvhBftA==; Date: Sun, 15 Jun 2025 18:59:46 +0300 Message-Id: <86plf5ov0t.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Jimmy Yuen Ho Wong on Sun, 15 Jun 2025 16:40:42 +0100) References: <8634c4g6v0.fsf@gnu.org> <86y0tuqsut.fsf@gnu.org> <86tt4hoxs3.fsf@gnu.org> <86sek1ow4v.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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: Jimmy Yuen Ho Wong > Date: Sun, 15 Jun 2025 16:40:42 +0100 > Cc: 78777@debbugs.gnu.org > > Yes, and that lone call is never made in your scenario. > > So I'm no longer sure what problem are we discussing here. > > The lone call to insert-file-contents, as in step 5 of my reproduction. Calling insert-file-contents after typing in > a file buffer runs the after-change-functions hooks. When these hooks are run, the current buffer's file name > is seen to have been temporarily set to nil, which should not be the case. > > Is this clear? I understand what you are saying, but not why you think it's a bug. Once again, the call to after-change-functions in this scenario is done not from insert-file-contents, but from the function that decodes the text read from the file. That function runs in a temporary buffer, which has no associated file name. The Subject of this bug says "insert-file-contents should not set buffer-file-name yo nil", but what I found that insert-file-contents doesn't set buffer-file-name to nil. It's an illusion created by the way you use after-change-functions. From unknown Tue Jun 17 01:48:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil Resent-From: Jimmy Yuen Ho Wong Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Jun 2025 16:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78777 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78777@debbugs.gnu.org Received: via spool by 78777-submit@debbugs.gnu.org id=B78777.175000509916422 (code B ref 78777); Sun, 15 Jun 2025 16:32:01 +0000 Received: (at 78777) by debbugs.gnu.org; 15 Jun 2025 16:31:39 +0000 Received: from localhost ([127.0.0.1]:59292 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQqGc-0004EY-UL for submit@debbugs.gnu.org; Sun, 15 Jun 2025 12:31:39 -0400 Received: from mail-pl1-x630.google.com ([2607:f8b0:4864:20::630]:56462) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uQqGY-0004AF-1K for 78777@debbugs.gnu.org; Sun, 15 Jun 2025 12:31:32 -0400 Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-236470b2dceso30639095ad.0 for <78777@debbugs.gnu.org>; Sun, 15 Jun 2025 09:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750005084; x=1750609884; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/WIIFeTMa5YEvxww0NR7+SohlCY1+1RkcDqUBUBcQ+o=; b=JcDHUyJzBxxPSwRZKzT3g+JAkvuot/XPB2qk2/6s07DuKpaQnfE8xShUwvzbAxUs0F 3fXCw6oCs8NFlWHvp3vY51eR4V5WFRNY4lGpkewBCFwSeNX1RQtn5+6rrcYNvXoWrpkG jYUzPtyrAY3bJfnqB/jKHz4PxtLaexxx1IyVrl2votDQfAUbb2ij3CVX35GEhkm1ZD+p F5B20Lq59MPxZKdDevSW5JPe5WgjZ6x8zZ3UV1T/gCjdCCzNOhEl3/85d5yIlD07VYPx uYl5gHw8OSeqc7nYztEGidCIdsN9zAWm5b+y6B7GkQ7qRfkMmN5tNLcxxr2M4LN4bgRr zS/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750005084; x=1750609884; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/WIIFeTMa5YEvxww0NR7+SohlCY1+1RkcDqUBUBcQ+o=; b=ryk+DboeldcYwS5m5LDhsulfPq5i7enzpfKIJMh56lXhxvmnTc/qM9YXY8GWFK28Gg K12bPaQnLwxjKgrjjKzY/cxZ+A7hWNceTt2sa2feM7PNupSKykImsk/oK9AukLlezIPK G23yJmT9NkpuEDGyvZQV8vO/BwT3tNvQ74msHBE798W8soxHevxkvvtb/TXyOiiscXpg qQu1KYlZOb+u9B402piZtV38mGvAxguM6MZzC8pPXQA/c5TQ53r1m/+toSJKYsoLRqSg oiRHmverMpQQG/ofhcYaQS1OJ/VEpVkNWz60udzUEnNYosL/kOF4nGDvp2CDCw8p6MCW TaKA== X-Gm-Message-State: AOJu0Yyg8UtYDmk0EUUaX6P+2PlqWYGH/w3jnD7QHHXJRnyEOHauW3wb x49ZEgML4EGdi79o/P3WgIoRpjg3cALrjziuOh+vCB5N+UfdaJXkuTmqZoCTB/VWHp0XlGcJ0lF d+at9AmhNJrvMkDqKYvNOrOG6Za6xwqM= X-Gm-Gg: ASbGncvdPouFbm6G6zn+9v5YMk5iiG7yPESHyadlcg7v/1gSqvG6KGvIQYJXHyBfcWW 3+unI8piz+INt1dh+SpWcdp2/kY1pSWmYHKZ6Gedtgfv75KElwKKYqnEzdTqyu8km+bo6o23tQd spSPJ+D8ffCVYfBAtl4oNG8gb71Sb6f7aKCPwyucHDYfD505de0g3WAWPGEexZHeCH7acSYqoC5 Uizxw== X-Google-Smtp-Source: AGHT+IG6S5GoCg5Q1vSqaU9X84nUSUObPKK8hPiiIN6Bs95affgEPyqIQrCyP8knOpiYsdRU9QI3fbc/4UL6vMwSWa0= X-Received: by 2002:a17:903:18c:b0:234:bca7:2920 with SMTP id d9443c01a7336-2366b3ad36fmr98427205ad.24.1750005083527; Sun, 15 Jun 2025 09:31:23 -0700 (PDT) MIME-Version: 1.0 References: <8634c4g6v0.fsf@gnu.org> <86y0tuqsut.fsf@gnu.org> <86tt4hoxs3.fsf@gnu.org> <86sek1ow4v.fsf@gnu.org> <86plf5ov0t.fsf@gnu.org> In-Reply-To: <86plf5ov0t.fsf@gnu.org> From: Jimmy Yuen Ho Wong Date: Sun, 15 Jun 2025 17:30:47 +0100 X-Gm-Features: AX0GCFv7I5iwiFE2cecapLtQ9KJxyvlkbCd8PGsqNcQ826kzfZAAhCbhgXGUnAI Message-ID: Content-Type: multipart/alternative; boundary="0000000000005bdd9e06379ecff1" X-Spam-Score: 0.0 (/) 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 (-) --0000000000005bdd9e06379ecff1 Content-Type: text/plain; charset="UTF-8" > > I understand what you are saying, but not why you think it's a bug. > Once again, the call to after-change-functions in this scenario is > done not from insert-file-contents, but from the function that decodes > the text read from the file. That function runs in a temporary > buffer, which has no associated file name. > Because the docstring of after-change-functions says the hooks are called with the current buffer, and the current buffer at the time insert-file-contents is called, is the file buffer, not the code conversion buffer. The message printed out also indicated that the current buffer at the time the after-change-functions lambda is called is indeed the file buffer, not the code conversion buffer. The file buffer's buffer-file-name should not be set to nil by insert-file-contents or any function it calls. As far as I know, only `insert-file-contents` exhibits this undocumented behavior for any functions that change buffer contents. The guarantee of after-change-functions being called with the current buffer isn't very useful if crucial variables of the current buffer such as the buffer file name cannot also be guaranteed to remain the same. This use case is illustrated by the tickets I linked to in my original report. There exist many file formatter packages that replace the content of the current buffer with a temporary file with the formatted file content inside a before-save-hook due to slowness of replace-buffer-content. When these packages are used in combination with lsp-mode, which has a function added to after-change-functions that needs access to the current buffer's file name in order to synchronize the document between the editor and the language server. --0000000000005bdd9e06379ecff1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I understand what you are saying, = but not why you think it's a bug.
Once again, the call to after-change-functions in this scenario is
done not from insert-file-contents, but from the function that decodes
the text read from the file.=C2=A0 That function runs in a temporary
buffer, which has no associated file name.

<= div>Because the docstring of after-change-functions says the hooks are call= ed with the current buffer, and the current buffer at the time insert-file-= contents is called, is the file buffer, not the code conversion buffer. The= message printed out also indicated that the current buffer at the time the= after-change-functions lambda is called is indeed the file buffer, not the= =C2=A0code conversion buffer. The file buffer's buffer-file-name should= not be set to nil by insert-file-contents or any function it calls.=C2=A0A= s far as I know, only `insert-file-contents` exhibits this undocumented beh= avior for any functions that change=C2=A0buffer contents.

The guarantee of after-change-functions being called with the curre= nt buffer isn't very useful if crucial variables of the current buffer = such as the buffer file name cannot also be guaranteed to remain the same. = This use case is illustrated by the tickets I linked to in my original repo= rt. There exist many file formatter packages that replace=C2=A0the content = of the current buffer with a temporary file with the formatted file content= inside a before-save-hook due to slowness of replace-buffer-content. When = these packages are used in combination with lsp-mode, which has a function = added to after-change-functions that needs access to the current buffer'= ;s file name in order to synchronize the document between the editor and th= e language server.


--0000000000005bdd9e06379ecff1-- From unknown Tue Jun 17 01:48:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Jun 2025 09:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78777 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Jimmy Yuen Ho Wong Cc: 78777@debbugs.gnu.org Received: via spool by 78777-submit@debbugs.gnu.org id=B78777.175006496628822 (code B ref 78777); Mon, 16 Jun 2025 09:10:02 +0000 Received: (at 78777) by debbugs.gnu.org; 16 Jun 2025 09:09:26 +0000 Received: from localhost ([127.0.0.1]:41973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uR5qI-0007Uo-0T for submit@debbugs.gnu.org; Mon, 16 Jun 2025 05:09:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36770) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uR5qF-0007TL-Hz for 78777@debbugs.gnu.org; Mon, 16 Jun 2025 05:09:24 -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 1uR5q9-0000FQ-W8; Mon, 16 Jun 2025 05:09:18 -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=A0EVvOVEPiBbQFU9ZB/JZ+5FKP60eggKQe4mCcnBqBI=; b=pq4wp+H0NbdM SzQ0FhmOlc9yoz/Xcj4D+gURotg+zXC8l+cGqYfVdoIVlkvPM70gNSzvkuP+I6FKDp9JpGtPVxKDg l8vRra+fXvXYoSEiBoWN3k92z7QJGydsZUrbSGWvsxZtLOvr+HZFlv8TG2/21kiN8QIHq2VF0FVrd hkIIWLMnEHzrgt/WDoHoF/6cnpcjIO160Gbr+xqlLLuJ2fH6WrALLxpiIog7rk9Hlv5bP9YpSIUPk JpgnjaCqToa2SjGGdlnHUubA+SQ1wMP3pbjLcWKMkggddxmefoz8NIA1SQYJ6gtFe6nveA/SYMR+i T9tz0wm+fs7w6VvFJ/8ZJA==; Date: Mon, 16 Jun 2025 12:09:14 +0300 Message-Id: <86bjqooxxh.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Jimmy Yuen Ho Wong on Sun, 15 Jun 2025 17:30:47 +0100) References: <8634c4g6v0.fsf@gnu.org> <86y0tuqsut.fsf@gnu.org> <86tt4hoxs3.fsf@gnu.org> <86sek1ow4v.fsf@gnu.org> <86plf5ov0t.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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: Jimmy Yuen Ho Wong > Date: Sun, 15 Jun 2025 17:30:47 +0100 > Cc: 78777@debbugs.gnu.org > > I understand what you are saying, but not why you think it's a bug. > Once again, the call to after-change-functions in this scenario is > done not from insert-file-contents, but from the function that decodes > the text read from the file. That function runs in a temporary > buffer, which has no associated file name. > > Because the docstring of after-change-functions says the hooks are called with the current buffer, and the > current buffer at the time insert-file-contents is called, is the file buffer, not the code conversion buffer. The > message printed out also indicated that the current buffer at the time the after-change-functions lambda is > called is indeed the file buffer, not the code conversion buffer. The file buffer's buffer-file-name should not > be set to nil by insert-file-contents or any function it calls. As far as I know, only `insert-file-contents` exhibits > this undocumented behavior for any functions that change buffer contents. OK, I see what happens. insert-file-contents intentionally binds buffer-file-name temporarily to nil when it is called with REPLACE non-nil, during the deletion or insertion from the code-conversion buffer. It does that to avoid prompting the user via ask-user-about-supersession-threat, which in this case will confuse. So this is a feature, an intentional behavior. > The guarantee of after-change-functions being called with the current buffer isn't very useful if crucial > variables of the current buffer such as the buffer file name cannot also be guaranteed to remain the same. > This use case is illustrated by the tickets I linked to in my original report. There exist many file formatter > packages that replace the content of the current buffer with a temporary file with the formatted file content > inside a before-save-hook due to slowness of replace-buffer-content. When these packages are used in > combination with lsp-mode, which has a function added to after-change-functions that needs access to the > current buffer's file name in order to synchronize the document between the editor and the language server. I suggest that buffer-modification hooks use buffer-file-truename instead, it will provide the correct file name in this (and other) cases. From unknown Tue Jun 17 01:48:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil Resent-From: Jimmy Yuen Ho Wong Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Jun 2025 12:20:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78777 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78777@debbugs.gnu.org Received: via spool by 78777-submit@debbugs.gnu.org id=B78777.17500763954565 (code B ref 78777); Mon, 16 Jun 2025 12:20:04 +0000 Received: (at 78777) by debbugs.gnu.org; 16 Jun 2025 12:19:55 +0000 Received: from localhost ([127.0.0.1]:43992 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uR8ob-0001BK-Iu for submit@debbugs.gnu.org; Mon, 16 Jun 2025 08:19:54 -0400 Received: from mail-pf1-x435.google.com ([2607:f8b0:4864:20::435]:54723) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uR8oY-0001Af-M6 for 78777@debbugs.gnu.org; Mon, 16 Jun 2025 08:19:51 -0400 Received: by mail-pf1-x435.google.com with SMTP id d2e1a72fcca58-7489dfb71a8so1775621b3a.1 for <78777@debbugs.gnu.org>; Mon, 16 Jun 2025 05:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750076384; x=1750681184; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7aZbf8uuFFVoWrJOLIjc9Omp2tqFSdP/Bx0eJbt7/ak=; b=j1iYbPRWt3os5inhAufl2RCoqEPdx2nKho738yHJ4D5JhiuvCyB04PWzuzfc59bfOD fH5UuKyMLO5MXP8XISH93W21w84VKHdbTRs1f6qZGNLYTl3SNYcCJENckp5JCR9EGWj7 2tDPcOLOegCdlZOB8bRqb6WBVrcC9b0ujGxC8aEKESZi1Oml/zFbhR76jfUqLdzpj5it Fsxr8+QiA2kqp3Fkq5Yydz+0WvLvQ7mely+ECEDQDxZ7z3Wnc8/H9Nncbvt/ZKC6RdL2 3mpznnOcDjcpX4Am6KvVfoA6a/S5b9liLuAsyJF6VLm2DMv7wYcpPsvqH4MOJ2WSh+Q+ OVMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750076384; x=1750681184; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7aZbf8uuFFVoWrJOLIjc9Omp2tqFSdP/Bx0eJbt7/ak=; b=cSBVdNvNtDXA6fYFG9DKiEIGDWyIFwQKENp2+HYiXxUB1pVKltZ+YPIyi+WeUrQexS yhmUN30q76EBGBezXN/Mp0RwljQTzpccB8qHFot8lW2yG9lNUzyV08wjnN+TsSfbZB5L ZgUsFYfsH3ThBpWvWwrH8lNo7fstbSGzLVGvb0ZunNgW2UsAfEnxMNqXXY6WVDQ8C7DE 0arnj/KUfwh72n3RkgWiqxO2v+ViemwvwK1xx3qYFrdKtpkSMAR3p9aFYrewriwd8ZpN ef4fnMHVGiuY4RUeHjhZTSypIv4zKCxr8kWBGOyj1K3KIL+/PntiZTTX1Spzz2MgciLe eVfA== X-Gm-Message-State: AOJu0YxJq+iISXDbBBtVh7Rsjmz9W/xsyOUAcFo1CxphdEfwl18yVseH EwV1oYbbOP5AEkJA7Su77w4ULLhtNfhfejPsIQuYCtzAGEgUzr8j2UvisUPCK5f9wF4+Hsq8TPZ RO5B/3gp9wFarTyq19P0TQBMH5ZEL/e4= X-Gm-Gg: ASbGnctM0x5PeopuiiahrRcmnZWT1ED7c3Yt0Zlly14gdNLSimvNNnIZ7NC6NRKTG9c PT1jBK8HYnkVl3k+qC9uaxqEQ7VBXoQS+8XN0RH9csJhwynIsnZq7YSHU3fXq3RBq437GkIzail tJixtobi134NcWpjG40mS0USgYbYoffbzSZ04+jus+VEIjc8Fdbx405GHGtp2qknZ1SevFgA71e k/s6Q== X-Google-Smtp-Source: AGHT+IGBLIzXqblhq6r4WmZtwHQZtcZEt2+/oDQP+Q3OJLx7V9KrS1uDc83bEwP5ordu2UpYaW7oQY0dHGUnPPlrucU= X-Received: by 2002:a05:6a00:2186:b0:748:33f3:8da8 with SMTP id d2e1a72fcca58-7489cfc2976mr10174798b3a.5.1750076384069; Mon, 16 Jun 2025 05:19:44 -0700 (PDT) MIME-Version: 1.0 References: <8634c4g6v0.fsf@gnu.org> <86y0tuqsut.fsf@gnu.org> <86tt4hoxs3.fsf@gnu.org> <86sek1ow4v.fsf@gnu.org> <86plf5ov0t.fsf@gnu.org> <86bjqooxxh.fsf@gnu.org> In-Reply-To: <86bjqooxxh.fsf@gnu.org> From: Jimmy Yuen Ho Wong Date: Mon, 16 Jun 2025 13:19:08 +0100 X-Gm-Features: AX0GCFvgggnmNNYOsABtdqGTZNSnaDDKo4NHQGEjuKnEkUakr5NuuvGNTnM9fNk Message-ID: Content-Type: multipart/alternative; boundary="00000000000033d54c0637af69a6" X-Spam-Score: 0.0 (/) 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 (-) --00000000000033d54c0637af69a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 16, 2025 at 10:09=E2=80=AFAM Eli Zaretskii wrote= : > > From: Jimmy Yuen Ho Wong > > Date: Sun, 15 Jun 2025 17:30:47 +0100 > > Cc: 78777@debbugs.gnu.org > > > > I understand what you are saying, but not why you think it's a bug. > > Once again, the call to after-change-functions in this scenario is > > done not from insert-file-contents, but from the function that decodes > > the text read from the file. That function runs in a temporary > > buffer, which has no associated file name. > > > > Because the docstring of after-change-functions says the hooks are > called with the current buffer, and the > > current buffer at the time insert-file-contents is called, is the file > buffer, not the code conversion buffer. The > > message printed out also indicated that the current buffer at the time > the after-change-functions lambda is > > called is indeed the file buffer, not the code conversion buffer. The > file buffer's buffer-file-name should not > > be set to nil by insert-file-contents or any function it calls. As far > as I know, only `insert-file-contents` exhibits > > this undocumented behavior for any functions that change buffer content= s. > > OK, I see what happens. insert-file-contents intentionally binds > buffer-file-name temporarily to nil when it is called with REPLACE > non-nil, during the deletion or insertion from the code-conversion > buffer. It does that to avoid prompting the user via > ask-user-about-supersession-threat, which in this case will confuse. > > So this is a feature, an intentional behavior. > This is one silly hack. If the intention is to suppress some file lock interactive functions, isn't the Emacs convention to use some kind of inhibit-* variable? In my case, I don't even use file locks, I've set create-lockfiles permanantly to nil, there's no reason that any file lock related functions should be run at all. Can userlock--ask-user-about-supersession-threat be modified to check for create-lockfiles and a newly introduced inhibit-file-lock internal variable before running userlock--check-content-unchanged? This change also seems to have been introduced to before-change-functions are called at the right time , perhaps we should ask Stefan what the best thing to do here is. > > > The guarantee of after-change-functions being called with the current > buffer isn't very useful if crucial > > variables of the current buffer such as the buffer file name cannot als= o > be guaranteed to remain the same. > > This use case is illustrated by the tickets I linked to in my original > report. There exist many file formatter > > packages that replace the content of the current buffer with a temporar= y > file with the formatted file content > > inside a before-save-hook due to slowness of replace-buffer-content. > When these packages are used in > > combination with lsp-mode, which has a function added to > after-change-functions that needs access to the > > current buffer's file name in order to synchronize the document between > the editor and the language server. > > I suggest that buffer-modification hooks use buffer-file-truename > instead, it will provide the correct file name in this (and other) > cases. > This is not ideal. The Language Server Protocol does not specify how to handle symlinks, there is no guarantee that file content changes to the source of a symlink will also change the target, which as far as the language server is concerned, can very well be just 2 regular files. In addition, the expectation is that unless the user has explicitly changed the buffer-file-name by renaming the buffer and/or file, buffer-file-name should remain unmodified at all times from the user's perspective. Examining buffer-file-truename should only be used as a crutch to look up the target of a file symlink quickly without hitting the disk. Both of the above scenarios are not what's happening here. insert-file-content is simply writing to a buffer and after-change-functions are simply reacting to changes in the buffer, not the file on disk. --00000000000033d54c0637af69a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jun 16, 2025 at 10:09=E2=80= =AFAM Eli Zaretskii <eliz@gnu.org>= ; wrote:
> From: Jimmy Yuen Ho Wong &= lt;wyuenho@gmail.com= >
> Date: Sun, 15 Jun 2025 17:30:47 +0100
> Cc: 78777@d= ebbugs.gnu.org
>
>=C2=A0 I understand what you are saying, but not why you think it's= a bug.
>=C2=A0 Once again, the call to after-change-functions in this scenario = is
>=C2=A0 done not from insert-file-contents, but from the function that d= ecodes
>=C2=A0 the text read from the file.=C2=A0 That function runs in a tempo= rary
>=C2=A0 buffer, which has no associated file name.
>
> Because the docstring of after-change-functions says the hooks are cal= led with the current buffer, and the
> current buffer at the time insert-file-contents is called, is the file= buffer, not the code conversion buffer. The
> message printed out also indicated that the current buffer at the time= the after-change-functions lambda is
> called is indeed the file buffer, not the code conversion buffer. The = file buffer's buffer-file-name should not
> be set to nil by insert-file-contents or any function it calls. As far= as I know, only `insert-file-contents` exhibits
> this undocumented behavior for any functions that change buffer conten= ts.

OK, I see what happens.=C2=A0 insert-file-contents intentionally binds
buffer-file-name temporarily to nil when it is called with REPLACE
non-nil, during the deletion or insertion from the code-conversion
buffer.=C2=A0 It does that to avoid prompting the user via
ask-user-about-supersession-threat, which in this case will confuse.

So this is a feature, an intentional behavior.

Thi= s is one silly hack. If the intention is to suppress some file lock interac= tive functions, isn't the Emacs convention to use some kind of inhibit-= * variable? In my case, I don't even use file locks, I've set=C2=A0= create-lockfiles permanantly=C2=A0to nil, there's no reason that any fi= le lock related functions should be run at all.

Can userl= ock--ask-user-about-supersession-threat be modified to check for create-loc= kfiles and a newly introduced inhibit-file-lock internal variable before ru= nning userlock--check-content-unchanged?

This change also seems to = have been introduced to before-change-functions are called at the r= ight time, perhaps we should ask Stefan what the best thing to do here = is.
=C2=A0

> The guarantee of after-change-functions being called with the current = buffer isn't very useful if crucial
> variables of the current buffer such as the buffer file name cannot al= so be guaranteed to remain the same.
> This use case is illustrated by the tickets I linked to in my original= report. There exist many file formatter
> packages that replace the content of the current buffer with a tempora= ry file with the formatted file content
> inside a before-save-hook due to slowness of replace-buffer-content. W= hen these packages are used in
> combination with lsp-mode, which has a function added to after-change-= functions that needs access to the
> current buffer's file name in order to synchronize the document be= tween the editor and the language server.

I suggest that buffer-modification hooks use buffer-file-truename
instead, it will provide the correct file name in this (and other)
cases.

This is not ideal.=C2=A0The Lang= uage Server Protocol does not specify how to handle symlinks, there is no g= uarantee that file content changes to the source of a symlink will also cha= nge the target, which as far as the language server is concerned, can very = well be just 2 regular files.

In addition, the exp= ectation is that unless the user has explicitly changed the buffer-file-nam= e by renaming the buffer and/or file, buffer-file-name=C2=A0should remain u= nmodified at all times from the user's perspective. Examining buffer-fi= le-truename should only be used as a crutch to look up the target of a file= symlink quickly without hitting the disk. Both of the above scenarios are = not what's happening here. insert-file-content is simply writing to a b= uffer and after-change-functions are simply reacting=C2=A0to changes in the= buffer, not the file on disk.
--00000000000033d54c0637af69a6-- From unknown Tue Jun 17 01:48:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Jun 2025 14:00:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78777 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Jimmy Yuen Ho Wong , Stefan Monnier Cc: 78777@debbugs.gnu.org Received: via spool by 78777-submit@debbugs.gnu.org id=B78777.175008236213927 (code B ref 78777); Mon, 16 Jun 2025 14:00:05 +0000 Received: (at 78777) by debbugs.gnu.org; 16 Jun 2025 13:59:22 +0000 Received: from localhost ([127.0.0.1]:48044 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uRAMq-0003cO-SO for submit@debbugs.gnu.org; Mon, 16 Jun 2025 09:59:22 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50322) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uRAMn-0003ax-5T for 78777@debbugs.gnu.org; Mon, 16 Jun 2025 09:59: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 1uRAMf-0002KF-5x; Mon, 16 Jun 2025 09:59:09 -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=Hagb/qamApS30f8+ZNjamApueYGtHCDeWphhuwfZBXk=; b=hT2UiUcRfw7X FtrWBDc+FSIWfjimSAtV6u7fWmtTtMuvMuZ/aDQbV4f2ygojWOFRFwH5L6LFJClv0bR0CdvwrKaOX veYUoSlMz9umsfu5DZa7OjTxDiePTwQv2KNrgIIbCDaMtmNY2l6XvkK52nTPy/aJJqq+sgoRrmgsD Ex8vDnUvCJUmBE8Oy8kChuKar64spFCR4v1iDlGft8NWvK6Z/9aaCiz0IPLYbv1OYS4zAWviHL5U9 +AzEeIxddtV6DdBozMqzt4+dxO/60RITNruaBA212YGc7NooVk0gFfsF7L5m/KmEcnVcO15r5DGQC 6iRK6K4jrH2eH0wajnwV6w==; Date: Mon, 16 Jun 2025 16:58:43 +0300 Message-Id: <86sejzokj0.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Jimmy Yuen Ho Wong on Mon, 16 Jun 2025 13:19:08 +0100) References: <8634c4g6v0.fsf@gnu.org> <86y0tuqsut.fsf@gnu.org> <86tt4hoxs3.fsf@gnu.org> <86sek1ow4v.fsf@gnu.org> <86plf5ov0t.fsf@gnu.org> <86bjqooxxh.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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: Jimmy Yuen Ho Wong > Date: Mon, 16 Jun 2025 13:19:08 +0100 > Cc: 78777@debbugs.gnu.org > > OK, I see what happens. insert-file-contents intentionally binds > buffer-file-name temporarily to nil when it is called with REPLACE > non-nil, during the deletion or insertion from the code-conversion > buffer. It does that to avoid prompting the user via > ask-user-about-supersession-threat, which in this case will confuse. > > So this is a feature, an intentional behavior. > > This is one silly hack. Thank you for your kind words. Any hope of convincing you to use kinder language? > If the intention is to suppress some file lock interactive functions, isn't the Emacs > convention to use some kind of inhibit-* variable? In my case, I don't even use file locks, I've set > create-lockfiles permanantly to nil, there's no reason that any file lock related functions should be run at all. > > Can userlock--ask-user-about-supersession-threat be modified to check for create-lockfiles and a newly > introduced inhibit-file-lock internal variable before running userlock--check-content-unchanged? ask-user-about-supersession-threat is not about file locks, it's about discovering that the file was modified outside of this Emacs session (perhaps by another Emacs session or some other system command). > This change also seems to have been introduced to before-change-functions are called at the right time, > perhaps we should ask Stefan what the best thing to do here is. Perhaps. > I suggest that buffer-modification hooks use buffer-file-truename > instead, it will provide the correct file name in this (and other) > cases. > > This is not ideal. The Language Server Protocol does not specify how to handle symlinks, there is no > guarantee that file content changes to the source of a symlink will also change the target, which as far as the > language server is concerned, can very well be just 2 regular files. An alternative is to go back to using replace-buffer-content. If its default operation is (or could be) too slow, you should be able to avoid that by passing zero for the MAX-SECS argument. > In addition, the expectation is that unless the user has explicitly changed the buffer-file-name by renaming > the buffer and/or file, buffer-file-name should remain unmodified at all times from the user's perspective. > Examining buffer-file-truename should only be used as a crutch to look up the target of a file symlink quickly > without hitting the disk. Both of the above scenarios are not what's happening here. insert-file-content is > simply writing to a buffer and after-change-functions are simply reacting to changes in the buffer, not the file > on disk. Can you explain what exactly is the problem with buffer-file-name being nil in the cases where you found that? If the problem is that a function placed on the after-change-functions hook doesn't expect that, it should be easy to amend the function to deal with the problem, no? IOW, would it solve the problem if the after-change hook simply did nothing when buffer-file-name is not a valid file name? If not, why not? From unknown Tue Jun 17 01:48:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Jun 2025 15:15:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78777 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Jimmy Yuen Ho Wong Cc: Kenichi Handa , Eli Zaretskii , 78777@debbugs.gnu.org Received: via spool by 78777-submit@debbugs.gnu.org id=B78777.175008689431362 (code B ref 78777); Mon, 16 Jun 2025 15:15:04 +0000 Received: (at 78777) by debbugs.gnu.org; 16 Jun 2025 15:14:54 +0000 Received: from localhost ([127.0.0.1]:48259 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uRBXw-00089W-NU for submit@debbugs.gnu.org; Mon, 16 Jun 2025 11:14:54 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:58698) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uRBXs-00087x-Ed for 78777@debbugs.gnu.org; Mon, 16 Jun 2025 11:14:49 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B1A7D4412A6; Mon, 16 Jun 2025 11:14:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1750086872; bh=m14BengzJO+M9gQwqTagTgPqS5ZKub28VM23Ez+gIXE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=h+9o3bz5Ig53h+nmt1IJMZ+kEkXNGIGH+hBPByGm5JgzKFWASeehjmeyvHWUT7yc2 cVlBS7wNaFmLh2N3Ieo8Y86LoFpoHWl99HSjqquJ9W0YjSCImpLKLMNg4LMido2J7s 8JP0Qfid559OnqTJJhVcV8Lr8tDz4LPFZx96IAIe93JgYUALJLxLVovd3VpSA26YH0 KwqI33oktfwWLxWtaksfzIlpqxTO1jwkmS6drfLxza1XSYOlvALjMhPSKOejUnjyIu 0y+gDHkD/iCxHOW6Wy9WwPyLV5E2QBpIAw/fTzR02pC2cnKMznII11f2WS/AmSnCW9 ZBorymQx3voFg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id AF3874414D4; Mon, 16 Jun 2025 11:14:32 -0400 (EDT) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9C72A12062E; Mon, 16 Jun 2025 11:14:32 -0400 (EDT) From: Stefan Monnier In-Reply-To: Message-ID: References: <8634c4g6v0.fsf@gnu.org> <86y0tuqsut.fsf@gnu.org> <86tt4hoxs3.fsf@gnu.org> <86sek1ow4v.fsf@gnu.org> <86plf5ov0t.fsf@gnu.org> <86bjqooxxh.fsf@gnu.org> Date: Mon, 16 Jun 2025 11:14:20 -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.164 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-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 (---) > Can userlock--ask-user-about-supersession-threat be modified to check for > create-lockfiles and a newly introduced inhibit-file-lock internal variable > before running userlock--check-content-unchanged? > > This change also seems to have been introduced to before-change-functions > are called at the right time > , > perhaps we should ask Stefan what the best thing to do here is. No, if you look at the diff, you'll see that this just moved the `specbind`. It was introduced earlier by: ```diff commit d07af40d882673ccb30c267a617e673c22a85ee4 Author: Kenichi Handa Date: Mon Oct 23 12:40:32 2006 +0000 (Finsert_file_contents): On replacing, temporarily bind buffer-file-name to Qnil before calling insert_from_buffer. diff --git a/src/fileio.c b/src/fileio.c --- a/src/fileio.c +++ b/src/fileio.c @@ -4359,8 +4359,12 @@ inserted_chars = (buf_bytepos_to_charpos (XBUFFER (conversion_buffer), same_at_start + inserted) - same_at_start_charpos); + /* This binding is to avoid ask-user-about-supersession-threat + being called in insert_from_buffer (via in + prepare_to_modify_buffer). */ + specbind (intern ("buffer-file-name"), Qnil); insert_from_buffer (XBUFFER (conversion_buffer), same_at_start_charpos, inserted_chars, 0); /* Set `inserted' to the number of inserted characters. */ inserted = PT - temp; ``` I'm not sure exactly what was the motivation for the change. I mean, the comment explains that the purpose is to silence a potential `ask-user-about-supersession-threat`, but I don't know why we should care about such a possibility and why it would be right to silence it here. Nor do I understand why it was added to the code path where coding conversion was needed but not to the other one. I see that back in 2016 I apparently understood the situation a bit better (or at least I thought) because while moving the `specbind` I managed to improve the comment with: 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. */ but it's still insufficient for me to understand now what's going on. Handa? Stefan