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.