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

Previous Next

Full log

Message #1699 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>,
 Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Tue, 16 Aug 2022 09:43:56 -0400

>>>>>> There have been many more complaints about being unable to edit a file
>>>>>> with a 5000+ line comfortably, than about editing 100+ MB files.
>>>>> Also because we have things like so-long to handle the large file case.
>>>> These things are expedients for want of anything better, aren't they?
>>> Yes, just like the narrowing your use in your long lines patch.
>> That's... unfair.  These things turn off everything (in particular, the
>> major mode and font locking) and provide a bare-bones editing
>> experience. What we'd like now is to provide Emacs users a near-complete
>> editing experience in all buffers.
> And, by the way, what could be a better solution?

A solution that is humble enough to leave an open door for ad-hoc
case-specific handling of the problem.

> Without assuming that computers have infinitely fast CPUs, that is?

If the font-lock rules to use in the buffer depend on whether the first
line of the buffer starts with #! or not, then your narrowing will break
them even tho they could work perfectly fine in a 1TB buffer without
requiring an infinitely fast CPU (since they don't need to scan the
whole buffer: just the region of interest plus the first 2 chars).


        Stefan

Previous Next

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