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


View this message in rfc822 format

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: bug#56682: Fix the long lines font locking related slowdowns
Date: Wed, 27 Jul 2022 14:18:01 +0300
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  56682 <at> debbugs.gnu.org
> Date: Tue, 26 Jul 2022 17:17:29 -0400
> 
> > Allowing fontification-functions to search for arbitrarily complex
> > regexpes in an arbitrarily large buffer, each and every time they are
> > asked to to highlight a small chunk of the said buffer, is a recipe
> > for disaster.
> 
> `font-lock.el` could enforce a smaller scope in a more discerning way
> that narrowing can.
> 
> > If for some reason modes really need to go through to the whole
> > buffer to decide which highlighting to use, they should to do so outside of
> > fontification-functions, and ideally once, for example, when the file
> > is loaded.
> 
> With the current narrowing they can't even know why the buffer is
> narrowed and hence can't make an informed decision whether they should
> maybe widen to look elsewhere.

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.




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

Previous Next


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