>> Eli Zaretskii [2022-08-07 17:20:52] wrote:
>> > jit-lock calls the functions with two arguments, BEG and END, and
>> > expects them to work only on that chunk of text.
>>
>> That is not the case: it expects the function to "fontify" *at least*
>> from BEG to END, but is quite happy to let it fontify more (and the
>> function can return a value indicating which portion was actually
>> returned in that case). Furthermore, it's clear that fontification of
>> BEG..END may need to look at text before BEG (and occasionally beyond
>> END as well).
>
> The intent is clearly that fontifications don't look far beyond these
> two points, because otherwise the whole design of jit-lock and its
> invocations during redisplay is basically thrown out the window.
Usually, font-lock rules don't look before BOL or after EOL, indeed,
*except* via `syntax-ppss` which does look at all the text from BOB
to point. To make up for that, `syntax-ppss` relies heavily on caching,
so that it *usually* doesn't need to look very far at all (and if
there's no `syntax-propertize-function`, it's usually quite fast
because it's fully coded in C).
For GB-sized buffers, even the fast C code of `syntax-ppss` incurs
a significant delay in the "unusual" case, so have various options:
- suck it up (potentially wait several minutes when jumping to the end
of the file).
- give up providing more or less correct highlighting (either via some
arbitrary narrowing like we do now, or turning off font-lock).
- try and find some clever heuristic that can find a "nearby safe spot",
i.e. a position for which we can guess the PPSS value (usually we
look for a position that is "known" to be outside of any string,
comment, or parenthesis).
- display the buffer quickly without highlighting while the fontification
is computed in the background.
I know CC mode relies on heuristics to identify syntactic structures, and not a full parser (whether from semantic or LSP), but it seems the issue is that you don't have a parse state for the beginning of the narrowed buffer, where an initial parse state is inappropriate. Assuming that text outside the narrowing is not allowed to change, determining the appropriate parse state should only be required once on narrowing.
So, could there be a pre-narrowing hook to run before narrowing takes effect to allow a major mode to determine the appropriate parse state for the beginning of the narrowed buffer?
Also, as I'm not a big user of explicit narrowing, the only place I've noticed it happening is in info mode, where the focus is narrowed to a particular syntactic unit.
Is there a way for a major mode to let the user signal the syntactic unit that they believe they are narrowing to, either with command variants or an interrogative(with a list of options supplied by the mode) when narrowing is performed by the user interactively? With the fall-back of either having the mode determine the correct initial state or turning off fontification during the narrowing?
Lynn