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

[Dmitry Gutov]

On 05.08.2022 17:22, Eli Zaretskii wrote:
> > Date: Fri, 5 Aug 2022 16:04:08 +0300
> > Cc:larsi@gnus.org,emacs-devel@gnu.org,gregory@heytings.org
> > From: Dmitry Gutov<dgutov@yandex.ru>
> >
> > On 05.08.2022 14:20, Eli Zaretskii wrote:
> > > 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.
> > As I said, changing long-line-threshold's default is not the solution
> > because this variable also determines when the fixes for the other
> > redisplay logic come into play.
> >
> > And those cause sluggishness more extensively and much earlier than
> > font-lock becomes a problem.
> That's incorrect, or at least inaccurate: part of slow redisplay is
> due to the fact that we fontify as part of displaying or as part of
> layout calculations.

The slow part I'm referring to is not in font-lock's code, nor in CC 
Mode's font-lock rules. So it can be "fixed" independently.

Because while it's still there, it makes debugging and optimizing 
font-lock code and major modes's font-lock rules harder.