bug#56682: Fix the long lines font locking related slowdowns

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 30 Jul 2022 11:34:03 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, larsi@gnus.org, 
>     monnier@iro.umontreal.ca
> 
> C-s aan SPC RET positions point at 730072.  When typing C-s aan SPC in a 
> not yet fontified buffer, it->narrowed_begv and it->narrowed_zv are 
> correctly positioned around that position, at 706860 and 732564 
> respectively.  But the iterator is late, and is still at the position at 
> which it was after C-s aan (without SPC); the first occurrence of "aan" is 
> at 152274, the corresponding narrowing bounds are 128520 and 154224, which 
> means that it has stopped at 154224.  So if we "reseat" the narrowing for 
> fontification-functions around the position 154224 of the iterator, the 
> narrowing becomes 141372-167076, which is well before the position of "aan 
> ", namely 730072.  At that point, isearch has found a match, and puts the 
> match overlay at 167076 (the last possible position of the narrowed 
> portion) and beyond, instead of putting it at 730072.

What I see is that isearch puts the match overlay on text that starts
at 167076 and ends at 730068 (the latter is the beginning of the
match), instead of on text between 730068 and 730072.

> In short, it seems to me that using the position of the iterator is a too 
> fragile solution, and that it is better to not apply a narrowing when the 
> iterator is outside of the narrowing bounds.

But this means we give up on the narrowing, which means the display
could be very slow.

And I've found the culprit: we weren't restoring point after lifting
the locked narrowing.  narrow-to-region can move point if the new
restriction puts point outside of the region.  So what was happening
is that isearch-update was calling pos-visible-in-window-group-p to
see whether the match is visible, and that call would move point from
under the feet of isearch-update, because pos-visible-in-window-p
calls display routines.  So any subsequent uses of point would use a
completely wrong value of point.

I've now made narrow-to-region preserve point across locked narrowing,
and the problem went away.

Ugh! this one was a bitch to debug!