GNU bug report logs - #55744
infinite loop

Previous Next

Full log

View this message in rfc822 format

From: "Daniel R. Grayson" <danielrichardgrayson <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 55744 <at> debbugs.gnu.org
Subject: bug#55744: infinite loop
Date: Wed, 1 Jun 2022 08:47:38 -0700

[Message part 1 (text/plain, inline)]

Ah, you're right -- if I wait 45 seconds or so, it finally finishes and
moves on,
and that file has strings that should have matched it.  And it needs to
match all the text
from the start of the file, since string starts and string ends look the
same.  And the result is the same
if I search for any other string that first occurs deep into the file.

Thanks, it's not a bug in emacs!



On Wed, Jun 1, 2022 at 8:35 AM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:

> "Daniel R. Grayson" <danielrichardgrayson <at> gmail.com> writes:
>
> > Okay, I did that, and it seems to be this:
> >
> > (defconst M2-mode-font-lock-keywords
> >           '("///\\(/?/?[^/]\\|\\(//\\)*////[^/]\\)*\\(//\\)*///" .
> > 'font-lock-string-face) )
>
> That's a regexp with a lot of backtracking, I think (i.e., elements that
> can be matched both by the ?'s as well as the two *'s).  So matching
> this will be slow, which results in the hangs you're seeing when Emacs
> is trying to match that to the text in the buffer.
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>

[Message part 2 (text/html, inline)]

Previous Next

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