|
From: | Dmitry Gutov |
Subject: | bug#56682: Fix the long lines font locking related slowdowns |
Date: | Tue, 16 Aug 2022 02:33:56 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 |
AFAICT mmm-mode does not try to do that at all.It does the wrapping through custom font-lock-fontify-region-function and syntax-propertize-function. The major mode specific values are saved after the major mode is called. Any subsequent modifications are just ignored.I'm not sure why they decided to wrap `fontification-functions`, but in theory it lets them support things like a submode that's using `nhexl-mode`, another using `nlinum-mode`, and yet another using `glasses-mode`.
I'm guessing this could also be implemented through a wrapping jit-lock-functions element if mmm-mode, say, saved the value of this variable corresponding to each major mode. Similarly to mmm-fontify-region-function.
But doing it in a caller up a level looks a little cleaner, of course.
In any case, these multi mode packages always need to "look back" in order to find which mode to use at a given position, so they inevitably need some kind of widening to work correctly.
Right. Even if they need to skip back just a little bit (usually), being able to look back is useful.
Although the "which mode" information is often available through an overlay or text property at point, so that need might be worked around in a lot of cases.
They'll get all the corresponding performance improvements (just-in-time fontification) as a bonus.Not sure what you mean by that. `fontification-functions` is already called "just-in-time" (and those packages don't re-implement jit-lock on their own, they just wrap themselves around jit-lock).Okay then. Sounds like somewhere in there there's a duplication of design still.I think the duplication is in the weird semantics of `fontification-functions`: this supposedly holds a list of functions, but it's difficult to make it work right with more than one function. I think it should be replaced with a single `fontification-function` instead.
I would try to go further: either document that `fontification-function' is ultimately supposed to call jit-lock, or call jit-lock-function directly (from handle_fontified_props or whatever), forcing polymode and multi-mode to use around-advice on that function (will that work on a function directly called from C?).
If we clarify that fontification has to go through jit-lock-function either way, we can more confidently move the application of font-lock narrowing to jit-lock-fontify-now (that's where fontification-functions and font-lock-ensure meet).
[Prev in Thread] | Current Thread | [Next in Thread] |