Re: Major modes using `widen' is a good, even essential, programming practice.

[Lynn Winebarger <owinebar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3162 bytes --]

On Mon, Aug 8, 2022, 5:29 AM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

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

[-- Attachment #2: Type: text/html, Size: 3986 bytes --]