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

Previous Next

Full log

Message #643 received at 56682 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Tue, 02 Aug 2022 04:10:12 -0400

> Given this situation, it sounds reasonable to start by restricting
> font-lock.

I fully agree.  The current behavior is the right default.

> As I wrote elsewhere, I'm okay with extending 'widen' so that it could
> "unlock" the locked narrowing, which could then be used in major modes
> that convince us their performance is adequate (or clearly announce in
> their docs that they don't care about files with long lines ;-).

`post-command-hook` also has been abused in all kinds of ways that suck
for the user if they have too-large buffers, or too many buffers, or too
many frames, or ...
That has never prompted calls to ban it completely.

So, I think it's important to provide this option to "unlock the
widening".  Even for purely philosophical reasons.

We can even add a user-option to "re-lock" the widening which would
prevent the "unlock the widening" from working, so that users can
override a poorly-thought-out use of widening which makes their large
file unusable (tho I'd argue that you can get the same result with an
`advice-add`).

Also, let's not forget that the speed impact of large buffers is not
limited to the redisplay, so trying to work extra-hard to eliminate all
possible cases of the redisplay spending too much time in large buffers
won't prevent "apparent lockups" where the time is spent in the command
(or some hook run at that occasion) rather than in the redisplay itself.


        Stefan

Previous Next

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