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

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: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Tue, 02 Aug 2022 05:25:09 -0400
>> `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 ...
> Indeed.  Which is why you'll see on the feature branch that in buffers with
> long lines post-command-hook is now also subjected to a locked narrowing.

But the problems can also affect buffers without long lines (just with
many lines).  Or the case of having a thousand buffers opened.  Or ...

>> 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`).
> I don't understand what you have in mind here.

If the major mode overrides the locked narrowing which causes the users
experience to be unbearable in long buffers, the users could set this
variable to override the override (while sending a bug report to the
major mode's maintainers and waiting for the bug to be fixed).

> It is not limited to redisplay only, but by far the largest fraction of the
> speed impact is (or rather was) in redisplay, and asymptotically
> so. Commands that used to take minutes on a reasonably recent computer now
> take a fraction of a second, only because redisplay is now faster.

Yes, your work is *really* appreciated in this area.  I'm just pointing
out that there's no point trying to make it technically *impossible* for
users to shoot themselves in the foot making redisplay too slow,
because there are still plenty of other ways they can shoot themselves
in the foot, and because every time we make something undesirable
impossible, we *also* make it impossible to do some desirable things
(even if we can't yet imagine what those might be).


        Stefan





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.