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

[Eli Zaretskii]

> Date: Fri, 5 Aug 2022 17:29:46 +0300
> Cc: acm@muc.de, larsi@gnus.org, emacs-devel@gnu.org, gregory@heytings.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> 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.

Then where is it?