bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21629: 25.0.50; python.el freezes up around docstrings.


From: Luke Powers
Subject: bug#21629: 25.0.50; python.el freezes up around docstrings.
Date: Thu, 8 Oct 2015 11:22:20 -0700

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 <jaccarmac@gmail.com>
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'





reply via email to

[Prev in Thread] Current Thread [Next in Thread]