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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Mon, 01 Aug 2022 15:08:16 +0300

> Date: Mon, 1 Aug 2022 04:23:21 +0300
> Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
>  Stefan Monnier <monnier <at> iro.umontreal.ca>
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> 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.

AFAIU, this seems to assume that highlighting is much faster than
syntax-ppss.  Is that a given?  If not, I don't think I understand how
this could help.

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

I don't.

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

flyspell-mode doesn't scan anything but the text you type, as you type
it.  Anything else must be explicitly invoked by the user.

Previous Next

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