[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: Eli Zaretskii
Subject: Re: How the long-lines "optimisation" breaks font locking.
Date: Fri, 05 Aug 2022 14:20:39 +0300

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

reply via email to

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