GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
View this message in rfc822 format
On Wed, 10 Aug 2022 07:47:44 +0000 Gregory Heytings <gregory <at> heytings.org> wrote:
>>
>> In any case, when I floor 'C-v' in dictionary.json now, whether narrowing is
>> applied in 'handle_fontified_prop' or not, I see the buffer stutter around
>> 2%, then go on and freeze around the 9% mark. When I release 'C-v' after
>> waiting a while, it ends up at 12% or 14%.
>>
>> Or if I go to EOB and floor 'M-v', both versions freeze almost right
>> away. So it doesn't look like one is an order of a magnitude faster than the
>> other, or at least not anymore.
>>
>> C-n and C-p are also pretty sluggish with both versions.
>>
>
> You must be doing something wrong in your tests. You have a faster computer
> than mine, and on my computer, with emacs -Q, neither C-v nor M-v nor C-n nor
> C-p are sluggish.
When I visit addons.json (from my Firefox directory), which is a single
line of (only) 19540 characters, and type `C-n' and hold down both keys,
the cursor stops moving almost immediately (on the third visual line)
and after letting go of the keys and waiting several seconds, point
jumps down the buffer to its actual position; likewise with `C-p'. This
is on master with -Q, and is no different from Emacs 28 (the only
difference I notice is that in master the buffer is wrongly fontified
from position 8235 to the end, while in 28 the entire buffer is
correctly fontified). Is this expected? (When I enable so-long-mode in
the buffer, holding down `C-n' or `C-p' produces no delay, both in
master and 28.)
Steve Berman
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.