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

[Eli Zaretskii]

> Date: Fri, 29 Jul 2022 16:37:14 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, larsi@gnus.org, 
>     monnier@iro.umontreal.ca
> 
> 
> >> At least if I do (pos-visible-in-window-p (point-max)), they are not: 
> >> handle_fontified_prop is not even called with it at point-max. Even 
> >> with (pos-visible-in-window-p (1+ (window-end))) 
> >> fontification-functions are not called.
> >
> > Try with vertical-motion.  Visit long-line.xml, go to position 20000, 
> > and then do "C-u 200 C-n" or "M-: (vertical-motion 200) RET.  Sooner or 
> > later you will see that it->current in handle_fontified_prop will be 
> > outside of the narrowing.
> >
> 
> Thanks, I was able to reproduce the bug with that recipe.
> 
> >> Should we perhaps be extra careful and add not apply the narrowing when 
> >> IT_CHARPOS is not between narrowed_begv and narrowed_zv?
> >
> > I'd rather narrow around IT_CHARPOS in that case.  That would be also 
> > consistent with what the doc string of fontification-functions now says.
> >
> > Perhaps we should also change what init_iterator does: if the start 
> > position with which it's called is outside of the restriction, recompute 
> > the restriction using the start point instead of the window's point 
> > position.  WDYT?
> >
> 
> 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.

Thanks.

> I don't know yet if it's necessary to add another similar recomputation 
> inside init_iterator.

I'll play with other callers of init_iterator and start_display, and
see if they can do similar things.