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

Previous Next

Full log

View this message in rfc822 format

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: bug#56393: Actually fix the long lines display bug
Date: Sat, 09 Jul 2022 11:48:27 +0000

>> It doesn't, see again the long-line-excerpt.xml file I sent you.  It is 
>> only 30K long, which would be a typical size for a restriction, and 
>> editing that file is slow when font locking is on and fast when font 
>> locking is off.
>
> I guess it's because we leave ZV at its original value, and font-lock 
> attempts to fontify the entire long line till the end?  Does it help to 
> make the value of syntax-wholeline-max smaller?
>

Sorry, I wasn't clear enough: I meant opening that file with Emacs from 
master.  Given that it's only 30K long, which would be a typical size for 
a temporarily narrowed buffer, and that editing it is slow, I don't see 
how applying a narrowing similar to the size of that file before calling 
fontification-functions could possibly help.

>> But fontification-functions are not the only problem here.  What I also 
>> observe is that, for example, moving in a fontified buffer takes (much) 
>> longer than moving in a non-fontified buffer.  For example, in 
>> long-line.xml, vertical-motion takes about 40 ms backward and 10 ms 
>> forward in a non-fontified buffer, and about 180 ms backward and 40 ms 
>> forward in a fontified buffer.
>
> I guess that's because vertical-motion calls the display code, and that 
> calls fontification-functions.
>

No, fontification-functions are not called when moving around in an 
already fontified portion of the buffer.  So the slowdown of C-n and C-p 
(and others) in that case is not caused by fontification-functions.

Previous Next

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