bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 25 Jul 2022 22:22:22 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Gerd Möllmann <gerd.moellmann@gmail.com>, 
>     andreyorst@gmail.com, 56683@debbugs.gnu.org
> 
> By the way, we should also decide what to do when the user enables 
> truncate-lines in a buffer with "really too long" lines.  With 
> DISP_INFINITY == 10000000 (its current value), and with a character pixel 
> width of 20 (a not uncommon value nowadays with HiDPI screens), lines 
> longer than 500000 (single-width) characters will not be displayed 
> correctly.  With a larger character pixel width, or with characters 
> occupying more than one column, that would be even less.
> 
> Given:
> 
> 1. that there has not been a single bug report about the fact that 
> truncate-line does not work correctly with "really too long" lines in the 
> last 20 years,

This might be because no one seriously visited such files in Emacs
until now.

> 2. that the limit above, caused by DISP_INFINITY, is not much more than 
> 10000, the default value for long-line-threshold, and
> 
> 3. the remaining slowdowns caused by truncate-lines,
> 
> I'd be in favor of simply disabling truncate-lines when 
> long_line_optimizations_p is set.

Maybe optionally.  Or maybe displaying a message/warning suggesting
that.  I don't like disabling truncate-lines unconditionally in such
buffers, I prefer leaving that to the user.

And I think we should use INT_MAX instead of DISP_INFINITY, for the
purpose of auto-hscroll.  (There are several other uses of that macro,
but I didn't yet look at all of them to see if it would make sense to
increase DISP_INFINITY itself.)