On 15.08.2022 21:28, Eli Zaretskii wrote: >> Date: Mon, 15 Aug 2022 21:17:23 +0300 >> Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca >> From: Dmitry Gutov >> >>>> I'm pretty sure that doing all that in Lisp is a good thing, and would >>>> be conducive to whatever improvements we might want to add later... >>> >>> No, because quite a few packages use jit-lock-register to run stuff >>> that is not font-lock at all, and I don't want that to slow down >>> redisplay when long lines are involved. And trying various values of >>> a variable exposed to Lisp is easy enough. >> >> It should also be possible to move the whole invocation of the >> fontification-functions up to Lisp > > How do you do that, given that these functions should be called from > redisplay with the region of buffer text only redisplay knows about? Something like in the attached patch. >> Another reason I chose font-lock-fontify-region, though, is that it's >> called from different places. It's the common entry point for font-lock. > > I have no problem with doing something similar in font-lock, I'm just > saying that it cannot be the only place. If we apply narrowing in handle_fontified_prop (or like in the attachment), and also in font-lock-fontify-region, it seems like every significant (*) execution path will go through two repetitions of the same logic. That's not ideal. (*) Significant by the metric of having impact on Emacs's performance, in large files especially. >> I've never seen fontification-functions contain anything but >> jit-lock-function, but jit-lock-functions is used by nlinum, for >> instance. And bug-reference-mode, and goto-address-mode. Perhaps we >> should ask Stefan's opinion on this. > > Stefan was and is on the CC list for the entire discussion. > >> And nlinum might not appreciate being narrowed. It seems to be working >> okay without that in my 20 MB XML file. And in 200 MB one too. > > Why is it important what nlinum does, when we have native line numbers > nowadays? Just an example of a mode which uses jit-lock-functions. With an implication that other, less known modes, might have similar needs and behavior. There aren't too many known examples.