GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
Message #649 received at 56682 <at> debbugs.gnu.org (full text, mbox):
>
> `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.
>
> 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. How would such a user
option be different from (setq long-line-threshold nil)? Do you mean that
we should make it possible for users to fine-tune each and every aspect of
the optimizations, with a bunch of user configurable options?
>
> 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.
>
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.
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.