bug#56393: Actually fix the long lines display bug

[Eli Zaretskii]

> Date: Thu, 21 Jul 2022 07:39:28 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: gerd.moellmann@gmail.com, larsi@gnus.org, 56393@debbugs.gnu.org
> 
> > 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?

If that's a temporary measure, I don't think we should do it: coding
it would be a throw-away effort.  I see no problem to have unfinished
code on master, we have that (for other features) all the time.  We
should delay such decisions until we either fix completely the
slowdown due to font-lock, or have a good understanding of the
reasons.

> > 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.

Then I guess this is not very important either way.  (Still, leaving
the text until we know exactly what, if anything, to say instead
sounds better to me than removing it and then possibly adding some of
it later.  But that's me.)