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

Previous Next

Full log

Message #50 received at 56683 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: andreyorst <at> gmail.com, 56683 <at> debbugs.gnu.org, gregory <at> heytings.org
Subject: Re: bug#56683: 29.0.50; long lines fix doesn't work correctly when
 lines are truncated
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.

>
>> 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 don't remember the offical name ATM.

Previous Next

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