Subject: Re: bug#58752: jit-lock-function infinite loop?
From: Eli Zaretskii <[email-masked]>
To: Alex Holehouse <[email-masked]>
Cc: [email-masked]
Date: Thu, 27 Oct 2022 19:17:47 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

> From: Alex Holehouse <[email-masked]>
> Date: Sun, 23 Oct 2022 18:37:37 -0500
> 
> Apologies if this is a reported and known issue, but after several hours of tracking this down, I think I've found
> a bug in the font-lock module when working with Python code on Emacs28 (macOS 12.6 on Apple Silicon
> (M1)). This is an issue certainly in Emacs 28 but not in earlier versions, so my temporary fix here is just to
> revert back to emacs 26; I haven't tested 27.
> 
> I think the issue stems from inside the jit-lock-function in font-lock.el, although my experience in hunting down
> emacs issues is limited. 
> 
> Specifically, it seems that the function falls into an infinite loop when trying to format ill-behaving Python code.
> The issue arises when a specific combination of things are true: an un-closed docstring that opens with three
> double quotes (but does not close) followed by docstrings in other functions with 4 or more examples of single
> quotation marks that are unsatisfied. These unsatisfied single quotation marks are, of course, allowed inside a
> docstring, which means even when editing a Python file, if the unclosed triple double-quote docstring appears
> event temporarily (e.g. as you're writing the docstring) the entire program freezes. 
> 
> I've narrowed this down to a minimal example that, at least in my setup (nothing fancy, vanilla emacs from
> both emacsformacosx and from homebrew), reproduces the issue. The code snippet can be found here:
> https://gist.github.com/alexholehouse/2259580ed2cb2caf75a16ee31d927465 
> 
> If you open this file in emacs, the code renders but if you scroll down emacs freezes, but can be unfrozen by
> running kill -SIGUSR2 <emacs PID> from another terminal window.

Thank you very much for your efforts to provide a minimal example.

I can reproduce this bug in Emacs 28, but not in Emacs 29.  So I think
the underlying bug was already fixed, and I'm therefore closing this
bug.