bug#59727: Problems with displaying long lines

bug#59727: Problems with displaying long lines

[Juri Linkov]

[A new bug report from bug#56682]

>> 1. after 'M-g TAB' (move-to-column) to 214748364 or more,
>>    the display is not updated anymore: moving point to the left
>>    from this position shows the cursor, moving point to the right
>>    has no visible effect.  Is it a hard limit in the display engine?
>>    Its hex value is #xccccccc.
>
> Sounds like a possible bug.  Does point move?  What does "C-x =" say about
> point if you move beyond column 214748364?

Point moves correctly:

point=214748362 of 1135341900 (19%) column=214748361 Hscroll=214748321
point=214748363 of 1135341900 (19%) column=214748362 Hscroll=214748322
point=214748364 of 1135341900 (19%) column=214748363 Hscroll=214748323
point=214748365 of 1135341900 (19%) column=214748364 Hscroll=214748324
point=214748366 of 1135341900 (19%) column=214748365 Hscroll=214748325

but the cursor motion is not visible.

> If you window is auto-hscrolled as result, then there is indeed hard limit:
> the X coordinate of a screen line is an 'int', so MAX_INT divided by the
> pixel-width of your default font is as far as we can go.

Maybe this limitation of auto-hscrolling should be documented?

>> 2. after starting Isearch at a large column number,
>>    Emacs hangs up indefinitely, e.g. with
>>    'M-g TAB 10000000 RET C-s' then even C-g doesn't get out.
>>    Debugging shows that the problem is in 'isearch-update'
>>    where the call to 'pos-visible-in-window-group-p' doesn't return.
>>    When this call is removed, the search is instantaneous.
>>    (Optimizing lazy-highlight is a separate problem in bug#56815.)
>
> I thought we agreed that calling pos-visible-in-window-p is not a good idea
> in this situation, since it will always think any position is visible?

Does pos-visible-in-window-p fail only on long lines?

>> PS: it seems these problems are not related to the locked narrowing,
>> rather the locked narrowing helped to expose them, so maybe they
>> should be reported in a new separate bug report?
>
> It is unrelated, because handling lines that are both very long and
> truncated on display uses a separate set of display shortcuts, and locked
> narrowing has almost no effect on that.

Ok, therefore a new bug report.

bug#59727: Problems with displaying long lines

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Wed, 30 Nov 2022 19:46:37 +0200
> 
> [A new bug report from bug#56682]
> 
> >> 1. after 'M-g TAB' (move-to-column) to 214748364 or more,
> >>    the display is not updated anymore: moving point to the left
> >>    from this position shows the cursor, moving point to the right
> >>    has no visible effect.  Is it a hard limit in the display engine?
> >>    Its hex value is #xccccccc.
> >
> > Sounds like a possible bug.  Does point move?  What does "C-x =" say about
> > point if you move beyond column 214748364?
> 
> Point moves correctly:

OK, then the new shortcuts in Emacs 29 for moving by columns in very long
and truncated lines do work reasonably.

> but the cursor motion is not visible.
> 
> > If you window is auto-hscrolled as result, then there is indeed hard limit:
> > the X coordinate of a screen line is an 'int', so MAX_INT divided by the
> > pixel-width of your default font is as far as we can go.
> 
> Maybe this limitation of auto-hscrolling should be documented?

We could document them, indeed.  But where? maybe in PROBLEMS?

> >> 2. after starting Isearch at a large column number,
> >>    Emacs hangs up indefinitely, e.g. with
> >>    'M-g TAB 10000000 RET C-s' then even C-g doesn't get out.
> >>    Debugging shows that the problem is in 'isearch-update'
> >>    where the call to 'pos-visible-in-window-group-p' doesn't return.
> >>    When this call is removed, the search is instantaneous.
> >>    (Optimizing lazy-highlight is a separate problem in bug#56815.)
> >
> > I thought we agreed that calling pos-visible-in-window-p is not a good idea
> > in this situation, since it will always think any position is visible?
> 
> Does pos-visible-in-window-p fail only on long lines?

Not long, truncated ones.  It doesn't understand that positions that are to
the left or to the right of the viewport are not "visible".

bug#59727: Problems with displaying long lines

[Juri Linkov]

>> but the cursor motion is not visible.
>>
>> > If you window is auto-hscrolled as result, then there is indeed hard limit:
>> > the X coordinate of a screen line is an 'int', so MAX_INT divided by the
>> > pixel-width of your default font is as far as we can go.
>>
>> Maybe this limitation of auto-hscrolling should be documented?
>
> We could document them, indeed.  But where? maybe in PROBLEMS?

Not sure how to document this limitation because it still works
to some extent: when lines are not truncated, and point can be
moved to the end of a 1 GB buffer, then after toggling line truncation
while point is at the end of the buffer, cursor motion is shown
correctly with auto-hscrolling near the end of the buffer.

>> >> 2. after starting Isearch at a large column number,
>> >>    Emacs hangs up indefinitely, e.g. with
>> >>    'M-g TAB 10000000 RET C-s' then even C-g doesn't get out.
>> >>    Debugging shows that the problem is in 'isearch-update'
>> >>    where the call to 'pos-visible-in-window-group-p' doesn't return.
>> >>    When this call is removed, the search is instantaneous.
>> >>    (Optimizing lazy-highlight is a separate problem in bug#56815.)
>> >
>> > I thought we agreed that calling pos-visible-in-window-p is not a good idea
>> > in this situation, since it will always think any position is visible?
>>
>> Does pos-visible-in-window-p fail only on long lines?
>
> Not long, truncated ones.  It doesn't understand that positions that are to
> the left or to the right of the viewport are not "visible".

I don't know how it works but the docstring of pos-visible-in-window-p
says:

  If POS is only out of view because of horizontal scrolling, return non-nil.

bug#59727: Problems with displaying long lines

[Eli Zaretskii]

> Cc: 59727@debbugs.gnu.org
> Date: Wed, 30 Nov 2022 19:55:36 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > > the X coordinate of a screen line is an 'int', so MAX_INT divided by the
> > > pixel-width of your default font is as far as we can go.
> > 
> > Maybe this limitation of auto-hscrolling should be documented?
> 
> We could document them, indeed.  But where? maybe in PROBLEMS?

Or we could bite the bullet and lift the restriction: make current_x be a
ptrdiff_t, and then audit all the gazillion places where we make
calculations with the X coordinate and make sure we use ptrdiff_t there.
Probably not for emacs-29.

bug#59727: Problems with displaying long lines

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 59727@debbugs.gnu.org
> Date: Wed, 30 Nov 2022 20:11:14 +0200
> 
> >> Does pos-visible-in-window-p fail only on long lines?
> >
> > Not long, truncated ones.  It doesn't understand that positions that are to
> > the left or to the right of the viewport are not "visible".
> 
> I don't know how it works but the docstring of pos-visible-in-window-p
> says:
> 
>   If POS is only out of view because of horizontal scrolling, return non-nil.

That's what I said, no?