Subject: bug#57684: locked narrowing breaks existing code without an apparent way to repair

From: Eli Zaretskii <[email-masked]>
Date: Fri, 16 Sep 2022 09:04:28 +0300

> From: Richard Stallman <[email-masked]>
> Cc: [email-masked]
> Date: Thu, 15 Sep 2022 23:38:15 -0400
> 
>   > Even if Elisp code is buggy, Emacs itself should never allow it to fall into an infinite loop and stop
>   > > responding to C-g, leaving full restart as the only way out.
> 
> It used to be impossible to have an infinite loop in Emacs Lisp that
> you could not quit out of.  The Lisp interpreter and tye bytecode
> interpreter both had calls to QUIT in all the loops of Lisp execution.
> Likewise, all the loops in C code that corresponded to Lisp loops, and
> might fail to terminate if given circular lists, such as Fmemq,
> had calls to QUIT.
> 
> If that is now no longertrue, what made it cease to be true?

It is still true.  The problem exists only with Lisp code that is run
when QUITs are either intentionally disabled, or when Lisp is run from
the display engine, where QUIT is caught and basically ignored.  The
particular case which started this thread is of the latter variety.