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

Previous Next

Full log

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 56682 <at> debbugs.gnu.org, larsi <at> gnus.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Sun, 31 Jul 2022 08:30:14 +0000

>
> It sounds...too drastic.
>

Are you sure?  The docstring already says "It is a bad idea to use this 
hook for expensive processing."  And Emacs already removes a function from 
the hook when it misbhaves.  Adding something like "In a too large buffer 
or in a buffer with long lines, the functions in this hook will only have 
access to a small portion of the buffer" seems coherent, at least to me.

>
> Once again, IME it is impossible to fix such problems only in low-level 
> C infrastructure.  There will always be left-overs and fallouts that 
> should be fixed locally in Lisp where they happen. There's no problem 
> here, and I don't expect us to be able to fix everything by a small 
> number of quick fixes, and declare a victory once and for all.
>

I both agree and disagree with that.  It is true that it is, strictly 
speaking, impossible to fix _all_ such problems _only_ in low-level C 
intrastructure, and that there will always be left-overs.  But it is 
possible to fix _most_ of these problems only in low-level C 
infrastructure, and we should do so, just like an operating system kernel 
in which everything is done to avoid crashing the system/leaving it in an 
unusable state (which includes killing a mis-behaving process when 
necessary).  And we should do so even more when the amount of code to do 
so in the low-level C infrastructure remains small.

>
> Well, WDYT about a similar feature for very large files?  IOW, when the 
> buffer's size is above some threshold, turn on the 
> long_line_optimizations_p flag (which should perhaps be renamed to 
> better reflect its purpose) even if no long lines are seen?
>

I was thinking about such a feature indeed.  But it would be separate from 
the long_line_optimizations_p one, because the optimizations to activate 
in both cases are different, and their thresholds are different, too.

Previous Next

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