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

Previous Next

Package: emacs;

Reported by: Gregory Heytings <gregory <at> heytings.org>

Date: Tue, 5 Jul 2022 08:50:02 UTC

Severity: normal

Done: Gregory Heytings <gregory <at> heytings.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Ihor Radchenko <yantar92 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, Gregory Heytings <gregory <at> heytings.org>, larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
Subject: bug#56393: Actually fix the long lines display bug
Date: Sat, 09 Jul 2022 20:09:42 +0800
Eli Zaretskii <eliz <at> gnu.org> writes:

>> 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.
>
> That's very strange, since AFAIK moving in a non-fontified buffer
> involves both fontifications and display of the fontified text,
> whereas moving through a fontified buffer involves only the latter.
> FWIW, I've _never_ seen movement through fontified buffer being slower
> than in a non-fontified one.  I'd be very interested to know what
> slows down the movement in a fontified buffer.

I am not sure if it is related, but I do observe a slowdown when moving
across fontified buffer. This happens in really large buffers when
moving across invisible text. AFAIU, line-move-1 uses
next-single-property-change loop, which could be costly when the region
has a large number of discontinuous text properties.

In the scenario here, I doubt that invisible text is present. Still, it
might be worth checking for the code that loops over text property
regions.

Best,
Ihor




This bug report was last modified 3 years and 33 days ago.

Previous Next


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