GNU bug report logs - #56682
Fix the long lines font locking related slowdowns

Previous Next

Full log

Message #505 received at 56682 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Mon, 1 Aug 2022 04:23:21 +0300

On 01.08.2022 01:50, Gregory Heytings wrote:
> 
>>
>> But one big slow scan (and how slow it is actually depends on a 
>> particular major mode) followed by responsive editing sounds much 
>> better than what we've had before.
>>
> 
> Indeed.  But then the question is: is it possible to do that scan while 
> opening the file, before it becomes editable?

IIUC this state of affairs is caused by your chosen approach to speeding 
up font-lock (hard narrowing while it is called), which makes the 
initial call to syntax-ppss happen inside that narrowing as well.

The alternative being that font-lock would call syntax-ppss right away 
with no restriction, but then only apply highlighting to limited parts 
of the buffer.

> It is way better to wait
> a few seconds more while the file is being opened than to wait before
> two basic motion commands when the file is already opened.

I agree, yes.

>> So I would recommend against trying to solve this part right now.
>>
> 
> It doesn't only solve the syntax-ppss problem, it also makes 
> flyspell-mode usable in such files, for example.

Does flyspell-mode always scan the full buffer?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.