GNU bug report logs - #56393
Actually fix the long lines display bug

Previous Next

Full log

Message #281 received at 56393 <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, larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
Subject: Re: bug#56393: Actually fix the long lines display bug
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.

Previous Next

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