Re: New optimisations for long raw strings in C++ Mode.

[Alan Mackenzie <acm@muc.de>]

Hello, Eli and Lars.

On Sun, Aug 07, 2022 at 19:17:50 +0300, Eli Zaretskii wrote:
> > Date: Sun, 7 Aug 2022 16:13:56 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > Simplest case to reproduce:

> > > M-: (setq long-line-threshold nil)

> > > Go to a cc buffer containing:

> > > char long_line[] = R"foo(

> > > )foo"

> > > M-: (insert (make-string 1000000 ?y))

> > > on the second line.  This reliably hangs Emacs for me.

> > Actually, when I try your recipe with make-string, it hangs for me, too,
> > for quite a few minutes.  Alternatively, when I do C-y, the insertion
> > takes a little less than a second.

> I actually tried the "C-y" recipe, and it hangs for me that way, too.

The problem was not so much the long line itself, but that there were too
many contiguous letters in it.  This caused (repeated) overflow of the
regexp engine stack in jit-lock.

Just as a matter of interest, my functions (not yet committed) for
dumping backtraces after a redisplay error were very useful in
identifying the problematic regexp.

I fixed this regexp by replacing a "*" by a "\\{,1000\\}", in the hope
that nobody will want an identifier longer than 1000 characters.

I've committed the fix.  Now the sequence
(i) emacs -Q
(ii) M-: (setq long-line-threshold nil)
(iii) Insert opening and closing raw string delimiters into a C++ Mode
  buffer.
(iv) Put point between the delimiters.
(v) M-: (insert (make-string 1000000 ?y))

works in a reasonable amount of time (the last step takes under a second
on my system), especially considering that the code scans the inserted
string for a closing raw string delimiter.

-- 
Alan Mackenzie (Nuremberg, Germany).