bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gregory Heytings
Subject: bug#56682: Fix the long lines font locking related slowdowns
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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]