GNU bug report logs - #56683
29.0.50; long lines fix doesn't work correctly when lines are truncated

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: andreyorst <at> gmail.com, 56683 <at> debbugs.gnu.org, gregory <at> heytings.org
Subject: bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated
Date: Fri, 22 Jul 2022 14:54:37 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: andreyorst <at> gmail.com,  56683 <at> debbugs.gnu.org,  gregory <at> heytings.org
> Date: Fri, 22 Jul 2022 09:52:16 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Gerd Möllmann <gerd.moellmann <at> 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".

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.