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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 29 Jul 2022 20:02:47 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, larsi@gnus.org, 
>     monnier@iro.umontreal.ca
> 
> > Doing it in init_iterator is too early alas, with the above recipe at 
> > least init_iterator is called with charpos inside the narrowing bounds, 
> > after which the iterator moves outside the narrowing bounds.  So I fixed 
> > the bug in handle_fontified_prop.
> 
> 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?

The immediate reason for the wrong highlighting seems to be an overlay
whose end position is the match for "aan ", and whose start position
is much earlier in the buffer (about 600K characters earlier).  I
don't yet understand why and how this overlay comes into existence.
Hmm...