GNU bug report logs - #61436
Emacs Freezing With Java Files

Previous Next

Full log

Message #68 received at 61436-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>,
 Mats Lidell <mats.lidell <at> lidells.se>
Cc: Robert Weiner <rsw <at> gnu.org>, Hank Greenburg <hank.greenburg <at> protonmail.com>,
 61436-done <at> debbugs.gnu.org, acm <at> muc.de, Eli Zaretskii <eliz <at> gnu.org>,
 rswgnu <at> gmail.com
Subject: Re: bug#61436: Emacs Freezing With Java Files
Date: Sat, 14 Oct 2023 19:41:41 +0000

Hello, Jens and Mats.

On Fri, Oct 13, 2023 at 22:42:04 +0200, Jens Schmidt wrote:
> Hi Alan,

> Alan Mackenzie <acm <at> muc.de> writes:

> > To solve the bug, I'm amending the macro c-beginning-of-defun-1 so that
> > it only stops at a debug-prompt-regexp position when it also found a {.
> > Otherwise it will keep looping until it finds a better position or BOB.

> Thanks.

> > Then please confirm that the bug is indeed fixed.

> For the fun of it I tried Hank's initial testcase as well, which is a
> bit less straight-forward to set up.  The freezes are indeed gone with
> your patch.

Thanks for the testing.  Seeing as how both of you confirm the original
bug is fixed with the patch, I'm closing it with this post.

> But I noticed that which-function-mode, when rapidly moving through
> the file, cannot always determine the current function name, then
> displaying "[n/a]" in the mode line.

> And indeed, when executing the simplified test case

>   ./src/emacs -Q -l ~/tmp/init.el +181 ~/tmp/P1.java

> and then immediately hitting C-M-a, point jumps to the beginning of the
> preceeding catch clause (point=5779 of 18142) instead of BOD.

I can't reproduce this, even when setting defun-prompt-regexp to the
original large regexp from hui-select.el.

> This behavior is again tied to the `defun-prompt-regexp' used by
> Hyperbole - without that regexp C-M-a jumps to the real BOD.

Mats, I'm willing to work on that regular expression, and also the one
for C++.  As I mentioned earlier, I've got some tools which work on
regexps, in particular pp-regexp, which prints a regexp more readably on
several lines, and fix-re, which rewrites a regexp when it is
ill-conditioned in certain ways.

I foresee reverse engineering the regexps into more readable forms built
up by concatenating basic blocks.  For example for the java regexp I
would define

    (defconst id "[a-zA-Z][][_$.a-zA-Z0-9]*")

, and use this id in a largish concat form.

I'm also willing to share pp-regexp and fix-re with you(r team), if that
might help, on the understanding that neither is of release quality.

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.