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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 5 Aug 2022 10:56:20 +0000
> Cc: larsi@gnus.org, emacs-devel@gnu.org, gregory@heytings.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > 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?
> 
> No, it wasn't reasonable, but neither was it "hang indefinitely".

Many/most users would never wait for 90 seconds for such a simple
command.  So yes, it's "indefinitely" for all practical purposes.
(And imagine how long it would take in an unoptimized build that I'm
running every day.)

> The problem was a single font-lock clause, after whose removal, the M->
> took about 1 second (first time) in the file with a 1,000,000 long line.
> This clause can be put back into CC Mode and optimised, probably by
> checking for being inside a literal.
> 
> All the other sluggishness has also vanished with that change.  I still
> get the overflow in the regexp engine stack on inserting text.  That,
> again, is a bug that surely can be fixed.

Thanks.  Any improvements in font-lock of any major mode is welcome.
If/when enough of them get their act together, we might revisit the
default value of long-line-threshold, as I already said many times.

I also encourage the interested parties to submit changes to extend
'widen' so that it could optionally break the lock.  Then we could
allow using that option in modes whose font-lock is not misbehaving
with long lines.