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

Previous Next

Package: emacs;

Reported by: Gregory Heytings <gregory <at> heytings.org>

Date: Thu, 21 Jul 2022 18:01:01 UTC

Severity: normal

Done: Gregory Heytings <gregory <at> heytings.org>

Bug is archived. No further changes may be made.

Full log


Message #1543 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, 15 Aug 2022 21:28:14 +0300
> Date: Mon, 15 Aug 2022 21:17:23 +0300
> Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> >> I'm pretty sure that doing all that in Lisp is a good thing, and would
> >> be conducive to whatever improvements we might want to add later...
> > 
> > No, because quite a few packages use jit-lock-register to run stuff
> > that is not font-lock at all, and I don't want that to slow down
> > redisplay when long lines are involved.  And trying various values of
> > a variable exposed to Lisp is easy enough.
> 
> 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?

> Another reason I chose font-lock-fontify-region, though, is that it's 
> called from different places. It's the common entry point for font-lock.

I have no problem with doing something similar in font-lock, I'm just
saying that it cannot be the only place.

> I've never seen fontification-functions contain anything but 
> jit-lock-function, but jit-lock-functions is used by nlinum, for 
> instance. And bug-reference-mode, and goto-address-mode. Perhaps we 
> should ask Stefan's opinion on this.

Stefan was and is on the CC list for the entire discussion.

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




This bug report was last modified 2 years and 9 days ago.

Previous Next


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