GNU logs - #78777, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil
Resent-From: Jimmy Yuen Ho Wong <wyuenho@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 12 Jun 2025 16:59:01 +0000
Resent-Message-ID: <handler.78777.B.174974753627773 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 78777 <at> debbugs.gnu.org
From: Jimmy Yuen Ho Wong <wyuenho@HIDDEN>
Date: Thu, 12 Jun 2025 17:58:34 +0100
Message-ID: <m28qlwyk05.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=2a00:1450:4864:20::335;
 envelope-from=wyuenho@HIDDEN; 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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Jimmy Yuen Ho Wong <wyuenho@HIDDEN>
Subject: bug#78777: Acknowledgement (30.1; insert-file-contents should not
 set buffer-file-name to nil)
Message-ID: <handler.78777.B.174974753627773.ack <at> debbugs.gnu.org>
References: <m28qlwyk05.fsf@HIDDEN>
X-Gnu-PR-Message: ack 78777
X-Gnu-PR-Package: emacs
Reply-To: 78777 <at> debbugs.gnu.org
Date: Thu, 12 Jun 2025 16:59:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 78777 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
78777: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D78777
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 12 Jun 2025 18:20:02 +0000
Resent-Message-ID: <handler.78777.B78777.174975239816641 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Jimmy Yuen Ho Wong <wyuenho@HIDDEN>
Cc: 78777 <at> debbugs.gnu.org
Date: Thu, 12 Jun 2025 21:19:47 +0300
Message-Id: <8634c4g6v0.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <m28qlwyk05.fsf@HIDDEN> (message from Jimmy Yuen
 Ho Wong on Thu, 12 Jun 2025 17:58:34 +0100)
References: <m28qlwyk05.fsf@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> From: Jimmy Yuen Ho Wong <wyuenho@HIDDEN>
> 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.

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil
Resent-From: Jimmy Yuen Ho Wong <wyuenho@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 12 Jun 2025 19:36:01 +0000
Resent-Message-ID: <handler.78777.B78777.17497569183978 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 78777 <at> debbugs.gnu.org
MIME-Version: 1.0
References: <m28qlwyk05.fsf@HIDDEN> <8634c4g6v0.fsf@HIDDEN>
In-Reply-To: <8634c4g6v0.fsf@HIDDEN>
From: Jimmy Yuen Ho Wong <wyuenho@HIDDEN>
Date: Thu, 12 Jun 2025 20:34:30 +0100
Message-ID: <CAKDRQS7tZp_7SYS1Kh-zvUSuEnaRnzWQSoJvqMTRjO_fzt=19w@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000dc0dbc06376506be"
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--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 <eliz@HIDDEN> wrote:

> > From: Jimmy Yuen Ho Wong <wyuenho@HIDDEN>
> > 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

<div dir=3D"ltr"><div dir=3D"ltr"><div><br clear=3D"all"></div><div><div di=
r=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr">On Thu, Jun 12, 2025 a=
t 7:19=E2=80=AFPM Eli Zaretskii &lt;<a href=3D"mailto:eliz@HIDDEN">eliz@gn=
u.org</a>&gt; wrote:</div></div></div></div><div class=3D"gmail_quote gmail=
_quote_container"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">&gt; Fr=
om: Jimmy Yuen Ho Wong &lt;<a href=3D"mailto:wyuenho@HIDDEN" target=3D"_=
blank">wyuenho@HIDDEN</a>&gt;<br>
&gt; Date: Thu, 12 Jun 2025 17:58:34 +0100<br>
&gt; <br>
&gt; <br>
&gt; When investigating <a href=3D"https://github.com/emacs-lsp/lsp-mode/is=
sues/4782" rel=3D"noreferrer" target=3D"_blank">https://github.com/emacs-ls=
p/lsp-mode/issues/4782</a> and<br>
&gt; <a href=3D"https://github.com/purcell/emacs-reformatter/issues/63" rel=
=3D"noreferrer" target=3D"_blank">https://github.com/purcell/emacs-reformat=
ter/issues/63</a>, I&#39;ve discovered<br>
&gt; the following bug in insert-file-contents.<br>
&gt; <br>
&gt; Reproduction:<br>
&gt; <br>
&gt; 1. echo &quot;hello world&quot; &gt; ~/test.txt<br>
&gt; 2. emacs -q ~/test.txt<br>
&gt; 3. M-x eval-expression RET (add-hook &#39;after-change-functions (lamb=
da (&amp;rest _) (message &quot;buffer-file-name: %s, current-buffer: %s&qu=
ot; (buffer-file-name) (current-buffer))) nil t) RET<br>
&gt; 4. Type something into the buffer<br>
&gt; 5. M-x eval-expression RET (insert-file-contents (buffer-file-name) ni=
l nil nil t) RET<br>
&gt; 6. Switch to the *Messages* buffer and observe the buffer file name is=
 nil.<br>
&gt; <br>
&gt; Expectation:<br>
&gt; <br>
&gt; insert-file-contents should not set buffer-file-name to nil<br>
<br>
I don&#39;t think it does.=C2=A0 (buffer-file-name) returns nil when the ca=
ll<br>
is evaluated in the minibuffer, and I thin that&#39;s what you see.=C2=A0 A=
fter<br>
performing the above recipe the buffer-filename of the buffer that<br>
visits test.txt remains to be &quot;test.txt&quot;, at least in my testing.=
=C2=A0 So<br>
the only evidence that it&#39;s set to nil are the messages logged in<br>
*Messages*, and they are about a different buffer.<br></blockquote><div><br=
></div><div>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.<br><br>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.<br><br>In addition, the following will NOT result in insert-fi=
le-contents temporarily setting the buffer-file-name of the current buffer =
to nil:<br><br>(let ((coding-system-for-read &#39;no-conversion)</div><div>=
=C2=A0 =C2=A0 =C2=A0 (coding-system-for-write &#39;no-conversion))<br>=C2=
=A0 (insert-file-contents (buffer-file-name) nil nil nil t))<br><br>Which s=
uggests some of the code conversion logic in the C function is erroneously=
=C2=A0setting the current buffer&#39;s file-name to nil, and then running t=
he after-change-functions before resetting it.</div></div></div>

--000000000000dc0dbc06376506be--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 14 Jun 2025 14:52:05 +0000
Resent-Message-ID: <handler.78777.B78777.17499126902382 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78777
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Jimmy Yuen Ho Wong <wyuenho@HIDDEN>
Cc: 78777 <at> debbugs.gnu.org
Received: via spool by 78777-submit <at> 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 <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQSEE-0000cL-Bu
	for submit <at> 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 <eliz@HIDDEN>) id 1uQSEC-0000c5-Tf
 for 78777 <at> 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <CAKDRQS7tZp_7SYS1Kh-zvUSuEnaRnzWQSoJvqMTRjO_fzt=19w@HIDDEN>
 (message from Jimmy Yuen Ho Wong on Thu, 12 Jun 2025 20:34:30 +0100)
References: <m28qlwyk05.fsf@HIDDEN> <8634c4g6v0.fsf@HIDDEN>
 <CAKDRQS7tZp_7SYS1Kh-zvUSuEnaRnzWQSoJvqMTRjO_fzt=19w@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Jimmy Yuen Ho Wong <wyuenho@HIDDEN>
> Date: Thu, 12 Jun 2025 20:34:30 +0100
> Cc: 78777 <at> debbugs.gnu.org
> 
> On Thu, Jun 12, 2025 at 7:19 PM Eli Zaretskii <eliz@HIDDEN> wrote:
> 
>  > From: Jimmy Yuen Ho Wong <wyuenho@HIDDEN>
>  > 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil
Resent-From: Jimmy Yuen Ho Wong <wyuenho@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 15 Jun 2025 14:46:06 +0000
Resent-Message-ID: <handler.78777.B78777.174999875124906 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78777
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 78777 <at> debbugs.gnu.org
Received: via spool by 78777-submit <at> 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 <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQocG-0006TU-Dp
	for submit <at> 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 <wyuenho@HIDDEN>) id 1uQocC-0006SA-5b
 for 78777 <at> 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 <at> 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: <m28qlwyk05.fsf@HIDDEN> <8634c4g6v0.fsf@HIDDEN>
 <CAKDRQS7tZp_7SYS1Kh-zvUSuEnaRnzWQSoJvqMTRjO_fzt=19w@HIDDEN>
 <86y0tuqsut.fsf@HIDDEN>
In-Reply-To: <86y0tuqsut.fsf@HIDDEN>
From: Jimmy Yuen Ho Wong <wyuenho@HIDDEN>
Date: Sun, 15 Jun 2025 15:45:02 +0100
X-Gm-Features: AX0GCFuRQSbY75kP85g0DZOZLAyJy69SsU2a3Ea-rfnkHdD2EY-oKfYGLE-D8mM
Message-ID: <CAKDRQS4v=YOkso_=Nn81rYvqmvO9jgwoW4m+JhyOw+oSo6oMOg@HIDDEN>
Content-Type: multipart/alternative; boundary="00000000000021460506379d55dd"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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

<div dir=3D"ltr"><div dir=3D"ltr"></div><div class=3D"gmail_quote gmail_quo=
te_container"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think you=
r after-change-function is called not due to<br>
insert-file-contents inserting the text from the file, but from the<br>
functions that decode the file&#39;s text.=C2=A0 To see if this is true, ma=
ke<br>
your after-change-function show the name of the current buffer.=C2=A0 If<br=
>
I&#39;m right, you will see something like &quot; *code conversion works&qu=
ot; as<br>
the name of the buffer, in which case indeed buffer-filename is<br>
expected to be nil, and I don&#39;t see a bug here.<br></blockquote><div><b=
r></div><div>=C2=A0I have suspected the same as the only call to set a buff=
er&#39;s name to nil is found in the implementation of insert-file-contents=
 near the code conversion buffer, but that&#39;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&#39;s name correctly=
.<br><br>Curiously, if you save the file between step 4 and 5 from my repro=
duction instruction, the buffer-file-name is printed correctly.</div><div><=
br></div><div>Hope this=C2=A0helps.</div></div></div>

--00000000000021460506379d55dd--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 15 Jun 2025 15:01:02 +0000
Resent-Message-ID: <handler.78777.B78777.174999962929675 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78777
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Jimmy Yuen Ho Wong <wyuenho@HIDDEN>
Cc: 78777 <at> debbugs.gnu.org
Received: via spool by 78777-submit <at> 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 <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQoqQ-0007hv-Fd
	for submit <at> 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 <eliz@HIDDEN>) id 1uQoqL-0007fL-D2
 for 78777 <at> 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <CAKDRQS4v=YOkso_=Nn81rYvqmvO9jgwoW4m+JhyOw+oSo6oMOg@HIDDEN>
 (message from Jimmy Yuen Ho Wong on Sun, 15 Jun 2025 15:45:02 +0100)
References: <m28qlwyk05.fsf@HIDDEN> <8634c4g6v0.fsf@HIDDEN>
 <CAKDRQS7tZp_7SYS1Kh-zvUSuEnaRnzWQSoJvqMTRjO_fzt=19w@HIDDEN>
 <86y0tuqsut.fsf@HIDDEN>
 <CAKDRQS4v=YOkso_=Nn81rYvqmvO9jgwoW4m+JhyOw+oSo6oMOg@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Jimmy Yuen Ho Wong <wyuenho@HIDDEN>
> Date: Sun, 15 Jun 2025 15:45:02 +0100
> Cc: 78777 <at> 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?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil
Resent-From: Jimmy Yuen Ho Wong <wyuenho@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 15 Jun 2025 15:19:02 +0000
Resent-Message-ID: <handler.78777.B78777.17500007093676 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78777
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 78777 <at> debbugs.gnu.org
Received: via spool by 78777-submit <at> 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 <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQp7s-0000xA-6N
	for submit <at> 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 <wyuenho@HIDDEN>) id 1uQp7p-0000wZ-P7
 for 78777 <at> 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 <at> 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: <m28qlwyk05.fsf@HIDDEN> <8634c4g6v0.fsf@HIDDEN>
 <CAKDRQS7tZp_7SYS1Kh-zvUSuEnaRnzWQSoJvqMTRjO_fzt=19w@HIDDEN>
 <86y0tuqsut.fsf@HIDDEN>
 <CAKDRQS4v=YOkso_=Nn81rYvqmvO9jgwoW4m+JhyOw+oSo6oMOg@HIDDEN>
 <86tt4hoxs3.fsf@HIDDEN>
In-Reply-To: <86tt4hoxs3.fsf@HIDDEN>
From: Jimmy Yuen Ho Wong <wyuenho@HIDDEN>
Date: Sun, 15 Jun 2025 16:17:43 +0100
X-Gm-Features: AX0GCFsOX0OCiAXP1RfCot_06t3x5CZP7sqLceRiN5Ow85wKwdUo-czWaEhT2F0
Message-ID: <CAKDRQS43dwbkJGktwH73CyunmRSgEYLzZAq9s7nPGDhtKX0Stg@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000000d36d706379dca95"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">That&#39;s not what I see.=C2=A0 T=
he only call to after-change-functions that<br>
insert-file-contents does is not done in your recipe: if I set a<br>
breakpoint there, it is never hit.<br>
<br>
So I have no doubt that what you see is an unrelated call to<br>
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<br>
different, and I saw it in GDB.<br>
<br>
So, given what I see under a debugger, there&#39;s no bug here.<br>
<br>
Why did you think insert-file-contents should at all call<br>
after-change-functions in this scenario?<br></blockquote><div><br>I was nev=
er able to set up GDB as I&#39;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&#39;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.<br><br>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.</div></div></div>

--0000000000000d36d706379dca95--

Last modified: Sun, 15 Jun 2025 15:30:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.