Re: How the long-lines "optimisation" breaks font locking.

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 4 Aug 2022 10:44:05 +0000
> Cc: emacs-devel@gnu.org, Gregory Heytings <gregory@heytings.org>
> From: Alan Mackenzie <acm@muc.de>
> 
> Hello, Lars.
> 
> On Wed, Aug 03, 2022 at 21:03:56 +0200, Lars Ingebrigtsen wrote:
> > Alan Mackenzie <acm@muc.de> writes:
> 
> > > I don't think it is improbable that a C++ hacker will create a long line
> > > in a raw string.
> 
> > If you don't think that's improbable, then you should like the new
> > optimisations a lot -- ....
> 
> These "optimisations" break CC Mode.

They don't "break" it, they cause it occasionally produce inaccurate
fontifications.  And only when otherwise Emacs becomes unusable.

> > .... because if you, instead of a 10K line in that C++ file, inserted
> > a 1M line, then Emacs would previously hang indefinitely, but with the
> > optimisation, it doesn't.
> 
> Well I tried CC Mode with a 1,000,000 character raw string.  It was
> indeed a bit sluggish but "hang indefinitely" is an exaggeration.

Try it with a 20MB raw string, then.  And, for good measure, in an
unoptimized build.  These are the cases we are trying to make
workable.

If all you are saying is that the default value of long-line-threshold
is too low, we can definitely discuss a better value.

> Having loaded the file in C++ Mode (without the spiking of
> narrow-to-region and widen), it took 90 seconds for M-> (first time).

And you consider that reasonable?

> Moving point was sluggish, taking perhaps 1 to 3 seconds, as did
> scrolling by a screenful.

Did you try moving and the beginning of the buffer or at its end?  The
speed is very different.

> Inserting text in the middle of the line caused an overflow in the
> regexp engine stack.  Interfering with the raw string delimiters
> (specifically, changing the identifier in the delimiter at either
> end of the string) again took 90 seconds.

And this is in your opinion reasonable performance?

> Doing these things in the current master branch indeed appeared to be
> fast, but at one point an error in an after-change-function caused
> after-change-functions to get set to nil, crashing CC Mode.

If you can show a recipe for this problem, we will fix it.  This code
is WIP, so some problems definitely remain and should be reported and
fixed.