fwiw, I went through the tree with bisect and found 3928ef2dd5b8febf3b1d9c1bfb22af3698d16bea to be the first commit where the issue pops up. On Thu, Oct 8, 2015 at 7:27 AM, Andreas Röhler < andreas.roehler@easy-emacs.de> wrote: > > Am 06.10.2015 um 16:54 schrieb Eli Zaretskii: > >> From: Jacob MacDonald >>> Date: Tue, 06 Oct 2015 04:48:50 +0000 >>> >>> Begin from a fresh 'emacs -Q'. Create a Python file. Insert a long >>> docstring which contains a header line and then a long body which >>> includes a few line breaks and spaces in it. The docstring should look >>> something like this: >>> >>> """test header >>> >>> lorem ipsum... more text more text more text >>> x10 lines >>> ... >>> ... >>> """ >>> >>> Save the file and close emacs. Start a fresh 'emacs -Q'. Open dired in >>> the directory which contains the Python file you created. Navigate to >>> the file and try to open in from dired. Emacs will freeze indefinitely >>> and eat all the system resources it can. You can break the cycle by >>> pressing C-q many times, but the freeze happens again on every single >>> redisplay. If you wait awhile before cancelling the redisplay, you may >>> see that fontification has frozen somewhere in the middle of the >>> docstring. >>> >> It infloops in python-nav-end-of-statement. The loop there ends up >> one position before EOB, then jumps back to string-start, and so on >> and so forth, ad nauseam. >> >> I have no idea what causes this, but I hope Python-mode experts and >> perhaps Stefan (due to syntax stuff) will be able to figure this out. >> >> >> >> >> > With a while-loop reading complex conditions IMO there is always an > abstract danger. > > python-mode.el uses a heuristic exit: > > `py-max-specpdl-size' - default is `max-specpdl-size' > > > >