Subject: Re: bug#78916: 31.0.50; C-g fails to exit loop

From: Eli Zaretskii <[email-masked]>
Date: Sat, 28 Jun 2025 09:51:00 +0300

> From: Mike Kupfer <[email-masked]>
> Date: Fri, 27 Jun 2025 14:36:06 -0700
> 
> Recipe from 'emacs -Q':
> 
> 1. Save the test-data attachment to a file.
> 
> 2. Evaluate the following defun:
> 
> (defun do-test ()
>   (while (re-search-forward "bug#[[:digit:]]+:" nil t)
>     (search-backward "(\"bug")
>     (let (end (start (point)))
>       (forward-sexp)
>       (setq end (point))
>       (query-replace-regexp "\\(\"bug#[[:digit:]]+:\\).*\"" "\\1\""
> 			    nil start end))))
> 
> 3. Visit the test data file.  With point at the start of the buffer, run
> the do-test function, and press space a couple times.  Now press C-g.
> 
> Expected behavior:
> 
>   The do-test function stops executing, and point is left at the same
>   position where you pressed C-g.  (This is the behavior I see with
>   Emacs 30 and with a build derived from Emacs master 648453c04d9.)
> 
> Observed behavior:
> 
>   point progresses through the remaining sexps, without giving you any
>   query-replace prompt.  When do-test has finished, point is now after
>   '"bug#78900:"'.
> 
> The git hash reported below by 'report-emacs-bug' includes a few Lisp
> changes that I believe are unrelated to the issue, and which are
> unchanged from the Emacs master build that works as expected.  The
> corresponding git hash from master (for the buggy build) is a002ca79ee7.

I think the offending commit is this:

 commit 772c4f036c38efd2a81d3643ad0bd718033d3b7f
 Author:     Stefan Monnier <[email-masked]>
 AuthorDate: Thu May 22 09:32:33 2025 -0400
 Commit:     Stefan Monnier <[email-masked]>
 CommitDate: Thu May 22 09:33:14 2025 -0400

     (perform-replace): Make it work with F-keys in TTYs (bug#78113)

     * lisp/replace.el (perform-replace): Use `read-key`.
     * test/lisp/replace-tests.el (replace-tests-with-undo): Adjust accordingly.

The build from commit cb1b65f3923d5dcb88767f6736603ffbc4272557, 3
commits before that, doesn't exhibit this problem.