[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: Dmitry Gutov
Subject: Re: How the long-lines "optimisation" breaks font locking.
Date: Fri, 5 Aug 2022 17:29:46 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1

On 05.08.2022 17:22, Eli Zaretskii wrote:
Date: Fri, 5 Aug 2022 16:04:08 +0300
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.

reply via email to

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