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

Previous Next

Full log

Message #35 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 Heytings <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 08:51:56 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Thu, 21 Jul 2022 20:15:55 +0000
>> From: Gregory Heytings <gregory <at> heytings.org>
>> cc: andreyorst <at> gmail.com, 56683 <at> 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?

Previous Next

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