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

[Gregory Heytings]

> > Actually that doesn't work correctly.  A recipe:
> >
> > emacs -Q
> > M-: (progn (set-frame-width nil 119) (set-frame-height nil 38)) RET
> > C-x C-f dictionary.json RET y
> > C-s aan SPC
> >
> > Now you'll see that the last line at the bottom of the window, which 
> > does not contain "aan ", is highlighted.  Is the following okay from 
> > your point of view?
>
> I see the problem, but I don't understand how it could be related to 
> handle_fontified_prop.  The highlight in this case is the isearch 
> highlighting of matches, and those are shown via overlays, not via face 
> text properties, so AFAIK handle_fontified_prop doesn't handle them.
>
> Do you understand the relation of this to handle_fontified_prop?

I cannot claim that fully understand what happens, but see below.  What I 
do know is that that problem wasn't present before 9c12c3b7c5, and that it 
disappears with:

diff --git a/src/xdisp.c b/src/xdisp.c
index b1ee7889d4..8c62f088b8 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -4412,13 +4412,8 @@ handle_fontified_prop (struct it *it)
          ptrdiff_t begv = it->narrowed_begv ? it->narrowed_begv : BEGV;
          ptrdiff_t zv = it->narrowed_zv;
          ptrdiff_t charpos = IT_CHARPOS (*it);
-         if (charpos < begv || charpos > zv)
-           {
-             begv = get_narrowed_begv (it->w, charpos);
-             if (!begv) begv = BEGV;
-             zv = get_narrowed_zv (it->w, charpos);
-           }
-         Fnarrow_to_region (make_fixnum (begv), make_fixnum (zv), Qt);
+         if (begv <= charpos && charpos <= zv)
+           Fnarrow_to_region (make_fixnum (begv), make_fixnum (zv), Qt);
        }

As far as I understand, what happens is this:

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.

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.