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: 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: Thu, 21 Jul 2022 07:39:28 +0000
>
> I think the code is ready to be merged, but what about the 
> documentation?  The branch currently removes all traces of the 
> facilities we previously documented as possible remedies for poor 
> performance in these cases.  However, we do know that in some situations 
> redisplay and related commands are still very slow.  The NEWS entry on 
> the branch does say that font-lock is one reason for the slowdown.
>

As far as I can see, font locking is the one and only remaining cause of 
slowdowns that is under control of Emacs.  Mode-specific slowdowns can of 
course not be solved in Emacs.  So what about simply turning font locking 
off unconditionally when long lines are detected in a buffer, until the 
font locking slowdowns are fixed?

>
> So at least that part should be in the manual, perhaps in the form of a 
> shorter description of so-long mode (because one thing it does is 
> disable font-lock).  We can remove that later, if and when these 
> problems and any others we find are also resolved.
>

As I told you, I'll start working on the font locking slowdowns as soon as 
this branch is merged into master.  It shouldn't take more than a couple 
of weeks to fix them.




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.