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

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: andreyorst@gmail.com,  56683@debbugs.gnu.org,  gregory@heytings.org
> Date: Fri, 22 Jul 2022 09:52:16 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> 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 don't really see how this could help in general, because the
> > current_x member (what you call the "iterator position") will still
> > overflow at some point, and we can no longer do any layout decisions
> > for the X coordinate after that.
> >
> > Or what am I missing?
> 
> You were asking for a good value of DISP_OMEGA, that's at least what I
> understood.  My answer is -1, plus code changes.
> 
> That current_x can overflow is something completely different, IMO.  But
> now I'm cautious enough to ask what do you mean?  Overflowing which
> bound?  I read this as integer overflow, integer = the data type.

Yes, integer overflow.  This code:

              init_to_row_start (&it, w, cursor_row);
              if (hscl)
                it.first_visible_x = window_hscroll_limited (w, it.f)
                                     * FRAME_COLUMN_WIDTH (it.f);
              it.last_visible_x = DISP_INFINITY;
              move_it_in_display_line_to (&it, pt, -1, MOVE_TO_POS);

will keep producing glyphs inside move_it_in_display_line_to until
it gets to the position of point.  While producing glyphs,
it.current_x is incremented by the pixel-width of each produced
glyph.  After a large enough number of produced glyphs, it.current_x
will overflow INT_MAX.

> >> Your "ticks" check kicks in should be burn to much time because of the
> >> infinite last x, right?
> >
> > Sorry, I don't think I understand what you are asking here.  Please
> > elaborate or rephrase.
> 
> The thing you implemented in set_iterator_to_next we talked about.
> 
>   if (max_redisplay_ticks > 0)
>     update_redisplay_ticks (1, it->w);

I understood that part, but not the "should be burn to much time
because of the infinite last x" part, even if I replace "to" with
"too".