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

[Dmitry Gutov <dgutov@yandex.ru>]

On 16.08.2022 00:57, Stefan Monnier via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:

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