Subject: Re: bug#61436: Emacs Freezing With Java Files

From: Robert Weiner <[email-masked]>
Date: Sun, 15 Oct 2023 06:20:15 -0400

Hi Alan:

Would be great if you can improve those two regexps.  The only
requirement is that they be able to recognize all defuns in the two
languages as best a regexp can, so that the whole defun can be
selected based on finding the opening brace regardless of coding
style.

Thanks.

-- Bob

> On Oct 14, 2023, at 8:41 PM, Alan Mackenzie <[email-masked]> wrote:
>
> Hello, Jens and Mats.

>
>> On Fri, Oct 13, 2023 at 22:42:04 +0200, Jens Schmidt wrote:
>> Hi Alan,
>
>> Alan Mackenzie <[email-masked]> 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).