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

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 21 Jul 2022 20:15:55 +0000
>> From: Gregory Heytings <gregory@heytings.org>
>> cc: andreyorst@gmail.com, 56683@debbugs.gnu.org
>> 
>> > Is this related to the below (from xdisp.c)?
>> >
>> > #define DISP_INFINITY 10000000
>> >
>> > Maybe we should make "infinity" somewhat larger?  dictionary.json has a 
>> > single line that is 18922365 characters long, so it's "more than 
>> > infinity".
>> 
>> It is indeed, setting DISP_INFINITY to 1000000000 "fixes" that bug. 
>> But... how infinite is infinite?  (A near-philosophical question 😉)

Don't think too much about it, it didn't do good to Georg Cantor.  BTW,
Omega would be a really cool name for that INFINITY; the smallest
position beyond all finite x.

>> With a somewhat larger file (that one is only 20 MB) we'd have to increase 
>> it again.  If that's a hard-coded limit, I guess it's a sign that we 
>> should advise against using toggle-truncate-lines in buffer with long 
>> lines.
>
> We could enlarge the value to INT_MAX, or even make the X-coordinate
> members of the iterator structure have the type ptrdiff_t and then
> DISP_INFINITY could be PTRDIFF_MAX (which would be undesirable in
> general for performance reasons).  But that would not solve the
> problem completely, because the value is in pixels.  So with the
> largest possible line length, which is EMACS_INT_MAX characters long,
> we'd need at least 7 or 8 times that for the X-coordinate values, and
> we don't have that even in 64-bit builds.
>
> If we want to advise against truncate-lines in such buffers, perhaps
> toggle-truncate-lines should ask for confirmation in such cases, and
> the documentation should mention the limitation.
>
> Gerd, any ideas or comments?

I had to look around a bit, because I didn't remember that constant.  It
seems to have been introduced for horizontal scroll bars, I think.

If we really want infinity, how about setting last_visible_x to -1 in
that case.  But that requires checking/changing some places where
the iterator pisition is tested against last_visible_x.

I think that's okay.  WDYT?

Your "ticks" check kicks in should be burn to much time because of the
infinite last x, right?