[Top][All Lists]

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

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

From: Alan Mackenzie
Subject: Re: How the long-lines "optimisation" breaks font locking.
Date: Thu, 4 Aug 2022 10:44:05 +0000

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.

> .... 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.

Having loaded the file in C++ Mode (without the spiking of
narrow-to-region and widen), it took 90 seconds for M-> (first time).
Moving point was sluggish, taking perhaps 1 to 3 seconds, as did
scrolling by a screenful.  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.

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.

> Which is the point here.

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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