bug#56682: Fix the long lines font locking related slowdowns

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 28 Jul 2022 18:40:26 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, monnier@iro.umontreal.ca
> 
> > By multiplying a very long and truncated line enough times you can 
> > always make Emacs useless.  The speedups I have in mind scale linearly 
> > with the number of such lines, so eventually, with enough such lines, 
> > Emacs will always become very slow at some point, especially if the 
> > window is hscrolled very far to the right.
> 
> That's exactly my point: with long and truncated lines Emacs can become 
> unusable with a 20 MB file, with long lines Emacs does not become unusable 
> even with a 1 GB file.  And what I (and everybody I guess) wants is a 
> "full and complete" solution.

Feel free to want it and feel free to wait for it, or work on it.  But
that doesn't mean I or others cannot meanwhile install less "full and
complete" solutions that improve some use cases.  And any user can
always turn off truncate-lines in such buffers, if some particular use
case makes Emacs unusable for them, it's not like this possibility is
taken from them.

> > That's unrelated.  The branch was created for your work on font-lock, 
> > and if you are done with that, feel free to land it on master.  I can 
> > continue working on master, and/or will create a feature branch if I 
> > feel it's justified.
> 
> It's not unrelated, at least not in my mind.  The branch was initially 
> created to fix the remaining font-lock related issues, but this thread 
> discusses, and the branch contains, fixes to the other remaining issues. 

I worked on truncated-lines case on the branch because without the
improvements you installed it was impossible to do anything with that:
Emacs was too slow to allow reasonable debugging and measurements.
That is the only relation between the two.

I don't see any reason to delay landing the important improvements we
have on the branch.  It will allow more people to use those
improvements, and thus will contribute both to their stability and to
further progress in this direction.

> I don't want to close this bug without a "full and complete" solution, and 
> currently someone who has (setq truncate-lines t) in their init file or 
> who presses C-x x t will see Emacs become unusable with a file with long 
> lines.

The bug can be kept open, if you don't want to close it.  I don't
mind.

> What about the following course of action: I add a "disable truncate-lines 
> in buffers with long lines" feature, and you remove it/disable it/make it 
> optional later if/when you consider that your fixes make Emacs fast enough 
> with long-and-truncated lines.

No.  Please stop pressuring me into making a decision I'm not yet
ready to make.  There's absolutely no rush.

> And we can/should open a new bug report and branch to discuss these
> long-and-truncated lines issues and solution attempts.

Opening a new bug about that is fine by me.