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

Previous Next

Full log

View this message in rfc822 format

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: bug#56682: Fix the long lines font locking related slowdowns
Date: Tue, 16 Aug 2022 05:45:18 +0300

> Date: Tue, 16 Aug 2022 00:18:35 +0300
> Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> >> It should also be possible to move the whole invocation of the
> >> fontification-functions up to Lisp
> > 
> > How do you do that, given that these functions should be called from
> > redisplay with the region of buffer text only redisplay knows about?
> 
> Something like in the attached patch.

I fail to see the difference which would justify such a change.

> If we apply narrowing in handle_fontified_prop (or like in the 
> attachment), and also in font-lock-fontify-region, it seems like every 
> significant (*) execution path will go through two repetitions of the 
> same logic.
> 
> That's not ideal.

But not a catastrophe, either.

> >> And nlinum might not appreciate being narrowed. It seems to be working
> >> okay without that in my 20 MB XML file. And in 200 MB one too.
> > 
> > Why is it important what nlinum does, when we have native line numbers
> > nowadays?
> 
> Just an example of a mode which uses jit-lock-functions. With an 
> implication that other, less known modes, might have similar needs and 
> behavior. There aren't too many known examples.

Let's hear them hollering, and then see what are their problems.

Previous Next

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