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

From: Eli Zaretskii <[email-masked]>
Date: Fri, 22 Jul 2022 09:13:59 +0300

> Date: Thu, 21 Jul 2022 20:15:55 +0000
> From: Gregory Heytings <[email-masked]>
> cc: [email-masked], [email-masked]
> 
> > 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 😉) 
> 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?