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

[Eli Zaretskii]

> Date: Fri, 29 Jul 2022 15:19:49 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: gerd.moellmann@gmail.com, 56682-done@debbugs.gnu.org, larsi@gnus.org, 
>     monnier@iro.umontreal.ca
> 
> > Hmm...  I'm bothered by this code in handle_fontified_prop:
> >
> > if (it->narrowed_begv)
> >   Fnarrow_to_region (make_fixnum (it->narrowed_begv),
> >                      make_fixnum (it->narrowed_zv), Qt);
> >
> 
> Hmmm... that code has been on the branch for a week, and I didn't see 
> particular bugs.  Which doesn't mean there are none, of course.

It depends on what kind of bugs we expect.  I've seen in a debugger
that fontification-functions are called with POS outside the narrowed
region.  But since jit-lock simply does nothing in that case, this is
silently ignored.

> > This narrows the buffer around window's point position (since this is 
> > how narrowed_begv and narrowed_zv are computed), but the display 
> > iterator can be called for position outside this range. This is unlikely 
> > to happen when the function is called as part of actual redisplay of a 
> > window, but it can easily happen when the display code is used by other 
> > primitives, for example vertical-motion or pos-visible-in-window-p. 
> > What happens then is that fontification-functions are called with the 
> > argument POS that is outside of the restriction, and that can cause 
> > errors.  (jit-lock simply does nothing in that case, AFAICT.)
> >
> > Is this intended?
> 
> I'm not sure I understand how this could happen.  Can a non-visible part 
> of the buffer be fontified by fontification-functions when for example 
> pos-visible-in-window-p is called and eventually returns nil?

Yes.  Whenever the display code is called, it fontifies the portions
of the buffer that it moves through.  And that is in general
justified: if we didn't fontify, we could produce wrong results from
pos-visible-in-window-p, due to faces that change the font height.

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

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