emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alan Mackenzie
Subject: Re: New optimisations for long raw strings in C++ Mode.
Date: Sun, 7 Aug 2022 16:13:56 +0000

Hello, Lars.

On Sun, Aug 07, 2022 at 16:54:37 +0200, Lars Ingebrigtsen wrote:
> 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.

In the (insert <string>) recipe, when it finally finishes, I see the
following in *Messages*:

Error during redisplay: (jit-lock-function 27) signaled (error "Stack overflow 
in regexp matcher")
Error during redisplay: (jit-lock-function 1527) signaled (error "Stack 
overflow in regexp matcher")
Error during redisplay: (jit-lock-function 3027) signaled (error "Stack 
overflow in regexp matcher")
Error during redisplay: (jit-lock-function 4527) signaled (error "Stack 
overflow in regexp matcher")
Error during redisplay: (jit-lock-function 6027) signaled (error "Stack 
overflow in regexp matcher")
Error during redisplay: (jit-lock-function 7527) signaled (error "Stack 
overflow in regexp matcher")
Error during redisplay: (jit-lock-function 1000027) signaled (error "Stack 
overflow in regexp matcher")
Error during redisplay: (jit-lock-function 9027) signaled (error "Stack 
overflow in regexp matcher")
Error during redisplay: (jit-lock-function 10527) signaled (error "Stack 
overflow in regexp matcher")
Error during redisplay: (jit-lock-function 12027) signaled (error "Stack 
overflow in regexp matcher")
Error during redisplay: (jit-lock-function 13527) signaled (error "Stack 
overflow in regexp matcher")
....

and so on.  So it's a bug needing fixing, rather than systematic slowness.

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]