GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
On Wed, 10 Aug 2022 09:04:06 +0000 Gregory Heytings <gregory <at> heytings.org> wrote:
>>> 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.)
>>
>> That's not expected, no, and rather surprising because it would contradict
>> what we've seen so far. Can you post that file somewhere?
It contains nothing particularly personal, so I've attached it.
>> The only possible
>> reason I can see ATM is that the file contains Arabic characters, which are
>> (and will remain) slow.
No Arabic and only four non-ASCII characters (three occurrences of `’'
and one of `É').
> I forgot to mention: did you try after disabling show-paren-mode? It is known
> to slow down redisplay at the beginning and end of the buffer, and will
> eventually be automatically turned off in these buffers.
Disabling show-paren-mode makes no noticeable difference.
Steve Berman
[addons.json (application/octet-stream, attachment)]
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.