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

Previous Next

Package: emacs;

Reported by: Hank Greenburg <hank.greenburg <at> protonmail.com>

Date: Sat, 11 Feb 2023 20:47:02 UTC

Severity: normal

Found in versions 30.0.50, 29.1.50

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Robert Weiner <rswgnu <at> gmail.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Robert Weiner <rsw <at> gnu.org>, Hank Greenburg <hank.greenburg <at> protonmail.com>, Mats Lidell <mats.lidell <at> lidells.se>, 61436-done <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Subject: bug#61436: Emacs Freezing With Java Files
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 <acm <at> muc.de> wrote:
>
> 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).




This bug report was last modified 1 year and 115 days ago.

Previous Next


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