Subject: bug#56393: Actually fix the long lines display bug

From: Gregory Heytings <[email-masked]>
Date: Sat, 09 Jul 2022 09:49:36 +0000

>>> . You currently only apply the "restriction" in a few places where the 
>>> code calls functions like find_newline_no_quit.  What about the rest 
>>> of display code -- are you saying that it doesn't need to be 
>>> "restricted"? or do you intend to add that in the future?
>>
>> Yes, that's what I'm saying.  You asked me to make sure that the 
>> restriction would have the least possible impact, which I did.
>
> If this is enough, then it's great.  I'm just asking myself how come 
> font-lock, for example, no longer slows things down as it did before? Do 
> you understand why?
>

Font lock does slow things down, see the NEWS entry.  But it also slows 
things down on much smaller files (see the long-line-excerpt.xml file I 
sent you).  As I said, to me the slowdown of font locking is a separate 
problem, as is shown by the fact that turning it off removes the remaining 
slowdowns in many/most cases.  There are in fact four separate problems 
here:

1. slowdowns caused by long lines,

2. slowdowns caused by multibyte characters in long lines (which are not 
solved by solving 1),

3. slowdowns caused by font locking,

4. slowdowns caused by major and minor modes (pre and post-command hooks 
and the like).

This bug "only" solves 1 and 2.  And as I said, I can try to look at 3 if 
you want, but not now.