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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Tue, 26 Jul 2022 17:17:29 -0400

Gregory Heytings [2022-07-25 21:23:55] wrote:
>> Before using a blunt tool like the forced-narrowing now in
>> `feature/long-lines-and-font-locking`, I think we should try and figure
>> out *why* the recipe below is so slow.
> It's not a blunt tool, it's an appropriate tool to help making sure that
> Emacs remains responsive when large files are visited.

I'm not opposed to reducing the size of the text that's considered, but
doing it via narrowing is a blunt tool.

> Think of it as POSIX's ulimits.

That's also a blunt tool.

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


        Stefan

Previous Next

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