bug#63363: 28.2; emacs freezes opening python file w/ unclosed quotes

[James Mazer]

Disregard that -- until 29 is out, I just added

(defun python-nav-end-of-statement--bug-override (orig-fn &optional noend)
  (forward-line 1))
(advice-add 'python-nav-end-of-statement :around
   #'python-nav-end-of-statement--bug-override)

to my init.el (from https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58780). Seems to do the trick for now -- no more lost buffers :-)

On Wed, May 10, 2023 at 5:01 PM James Mazer <mazerj2006@gmail.com> wrote:

Just confirmed that with an emacs 29.0.90 snap (beta) I'm not seeing the lock up. So it appears to be fixed downstream, but would be nice to be able to fix in 28 until 29 is actually released :-)

On Tue, May 9, 2023 at 9:23 AM James Mazer <mazerj2006@gmail.com> wrote:

Yes, seems to be the same issue. I just tried replicating his trigger and locked up an emacs window.. here's the backtrace after sigusr2:

Debugger entered--entering a function:
* #f(compiled-function () #<bytecode 0xb893e2c8c539dfa>)()
  syntax-ppss()
  python-nav-end-of-statement()
  python-nav-end-of-block()
  python-info-statement-ends-block-p()
  python-nav--forward-sexp(-1 nil nil)
  python-nav-forward-sexp(-1 nil nil)
  python-nav-backward-sexp()
  python-info-docstring-p((0 nil 390 34 nil nil 0 nil 427 nil nil))
  python-font-lock-syntactic-face-function((0 nil 390 34 nil nil 0 nil 427 nil nil))
  font-lock-fontify-syntactically-region(180 1700 nil)
  font-lock-default-fontify-region(184 1684 nil)
  font-lock-fontify-region(184 1684)
  #f(compiled-function (fun) #<bytecode 0x19ba0a4f10e54dbd>)(font-lock-fontify-region)
  jit-lock--run-functions(184 1684)
  jit-lock-fontify-now(184 1684)
  jit-lock-function(184)
  redisplay_internal\ \(C\ function\)()

 

I'll see if I can spin up a version of 29. Been a while since I compiled emacs from scratch... I'm actually surprised that there aren't packages for 28 and 29 more readily available for ubuntu. Not sure what's up with that.

On Mon, May 8, 2023 at 9:09 PM Ruijie Yu <ruijie@netyu.xyz> wrote:

James Mazer <mazerj2006@gmail.com> writes:

> Don't have time right now to do a custom build, but as sanity check, I just quickly pulled the 28.2 gnu.org.emacs flatpak and tried that and I get
> exactly the same issue, so it doesn't appear to be specific to the snap build. I can't find a 29 snap or flatpak to test, though.

There is also another bug report (closed as fixed on 29), #62794, that I
think is the same as this report and #62325.  In particular, see this
message within that bug report:

msgid:ZDdE/j6dDbhCw1QF@nicku.org
https://mail.gnu.org/archive/html/bug-gnu-emacs/2023-04/msg00798.html

What Nick described in #62794 sounds exactly the same as your issue and
Eli's observation: that only _some type(s) of_ python files trigger the
error.  I, as well as Eli, were able to reproduce the issue of #62794
via using the file Nick attached in that message.

James, can you confirm that Nick's issue on #62794 is exactly the same
as yours in this bug report, and that you can also reproduce the issue
using Nick's attachment from that message?

And also, if you want to get a version of 29 to test, you can either get
the pretest or clone the code and run "make".  The resultant emacs
binary is located at "src/emacs".  Let me know if this is unclear.

--
Best,


RY

--

James Mazer

mazerj@gmail.com

--

James Mazer

mazerj@gmail.com

--

James Mazer

mazerj@gmail.com