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

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>
> 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.

Right.  I am not worried about that:

It takes a lot of iterations until the ints overflow.  The largest
positive 32-bit integer is very roughly 2 * 10^9.  With a font width of
of 10 pixels, that would mean 2 * 10^8 characters (200 Mb), and so on
with wider fonts.

Se that being said, what I orignally wanted to ask, was:

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

Sorry for the typo: s/be/we, i.e. "if we burn...".  What I meant to ask
is if the check above doesn't lead to a signal anyway long before we
reach the overflow.