GNU bug report logs - #63272
29.0.90; xref fails on long lines

Previous Next

Package: emacs;

Reported by: Juri Linkov <juri <at> linkov.net>

Date: Thu, 4 May 2023 15:16:03 UTC

Severity: normal

Tags: notabug

Found in version 29.0.90

Fixed in version 29.0.60

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

Full log


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

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 63272 <at> debbugs.gnu.org
Subject: Re: bug#63272: 29.0.90; xref fails on long lines
Date: Fri, 05 May 2023 20:50:19 +0300
tags 63272 notabug
close 63272 29.0.60
thanks

>> 1. Create a file with a long line, e.g. type
>>     a C-u 500000 b c
>> Save the file and commit to git.
>> (long-line-optimizations-p returns t)
>> 2. Try to search a regexp that matches the whole long line, e.g.
>>     C-x p g a.*c RET
>> Debugger entered--Lisp error: (error "Stack overflow in regexp matcher")
>
> Isn't that more like a problem with the regexp you entered, or with our
> regexp engine?
>
> E.g. try this:
>
>   C-x p g a[^c]*c RET

In the real case the prefix and suffix were unique, so I didn't expect
that in a generated file there was a very long distance between prefix
and suffix.  To limit the distance between prefix and suffix I tried:

  C-x p g prefix.{0,100}suffix

but xref that uses ripgrep fails to find matches.
So needed to fall back to ripgrep-based rgrep in this case:

  M-x rgrep prefix.{0,100}suffix

that works successfully.

It seems the problem is because of different regexp syntax
used by ripgrep and re-search-forward in xref--collect-matches-1.

Since this is a separate problem, I'm closing this one,
then a new feature request could be opened if you want.




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

Previous Next


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