GNU bug report logs - #55744
infinite loop

Previous Next

Package: emacs;

Reported by: "Daniel R. Grayson" <danielrichardgrayson <at> gmail.com>

Date: Tue, 31 May 2022 19:51:01 UTC

Severity: normal

Tags: moreinfo, notabug

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #31 received at 55744 <at> debbugs.gnu.org (full text, mbox):

From: "Daniel R. Grayson" <danielrichardgrayson <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 55744 <at> debbugs.gnu.org
Subject: Re: 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)]

This bug report was last modified 2 years and 351 days ago.

Previous Next


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