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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Fri, 5 Aug 2022 16:11:28 +0300
On 05.08.2022 16:00, Gregory Heytings wrote:
>>> Note that if it were 2/4/8/20 seconds once, and then no further 
>>> slowdowns while editing the file, that would perhaps be okay.  But 
>>> that's not the case, you will regularly see a similar 2/4/8/20 
>>> seconds delay.
>>
>> Do our users regularly edit 30MB files? And do a lot of changes in 
>> them? In different areas?
>>
> 
> You seem to think they do not.  Then why is it a problem if such files 
> are mis-fontified?

From experience, I might visit a medium-to-large sized file, and I 
might search for a particular identifier inside it. Much more rarely, I 
would apply some edit inside it, in one place, and then save the buffer.

On balance, there is more likely more reading than editing involved. 
That's why I think font-lock should be assigned more importance.

In all likelihood, the file I would visit would be even smaller than 
30MB, but big enough that the majority of your improvements will be 
noticeable and welcome there. Just not the part that breaks font-lock.




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.