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 #370 received at 56682 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Sat, 30 Jul 2022 11:12:39 +0300
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  56682 <at> debbugs.gnu.org
> Date: Sat, 30 Jul 2022 03:16:29 -0400
> 
> > Feel free to suggest better ways of handling these issues, or even
> > ways to solve this entirely inside font-lock.  If and when such
> > suggestions materialize, I'm sure we will be glad to use them instead
> > of less elegant/more direct solutions.
> 
> I'd suggest to keep things mostly as they are but move the decision to
> ELisp: i.e. pass the beg..end limits to jit-lock and let jit-lock do
> the narrowing.  This way it's easy to later refine the mechanism.

That's already happening: code called via fontification-functions can
access the restriction via point-min and point-max.  If you or someone
else can come up with efficient methods of using that information so
as not to go too far forward and back, we could consider removing the
lock from the narrowing.  But we'd need to see the code first and
assess the resulting performance with long lines.




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

Previous Next


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