bug#56682: locked narrowing

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  56682@debbugs.gnu.org,  Eli Zaretskii
>  <eliz@gnu.org>,  Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 30 Nov 2022 18:34:15 +0200
> 
> 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?

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.

> 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?

> 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.