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

From: Gregory Heytings <[email-masked]>
Date: Fri, 29 Jul 2022 15:19:49 +0000

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

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

Should we perhaps be extra careful and add not apply the narrowing when 
IT_CHARPOS is not between narrowed_begv and narrowed_zv?