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

[Lynn Winebarger <owinebar@gmail.com>]

On Mon, Aug 8, 2022 at 7:48 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Lynn Winebarger <owinebar@gmail.com>
> > Date: Mon, 8 Aug 2022 07:16:44 -0400
> > Cc: Eli Zaretskii <eliz@gnu.org>, Alan Mackenzie <acm@muc.de>, gregory@heytings.org,
> >       emacs-devel <emacs-devel@gnu.org>
> >
> > 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?
>
> Why do you need a hook?  When the mode is first enabled in the buffer,
> there will be no narrowing in effect yet, so the mode could do
> whatever it wants at that time.
>
> Of course, this won't help us to solve the issues discussed here,
> because scanning the entire buffer at any time is slow and
> non-scalable.
>
I think you answered your own question - the code (I believe we're
discussing jit-lock on arbitrarily long lines in the particular) doing
the narrowing would have to identify the starting and ending points
via some special variable prior to running the hook, so the thunks
would be able to determine the right state *before* narrowing is
actually done.


> > 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?
>
> We are not talking about user narrowing here.

Maybe not explicit user narrowing, but I don't think we're discussing
a piece of code that is just randomly jumping around a buffer,
narrowing and then requiring fontification without user interaction.
So, one way of handling it would be to have the code doing the
narrowing take the place of the user in the above scenario in some
programmatic way, perhaps using some prespecified (by the mode)
regular expressions to make a best guess at what the user response
would be based solely on local conditions.  A mode that doesn't
specify a way to make a selection could be defaulted to turn off
fontifcation while narrowing.

An approach that doesn't require cooperation from the mode would be to
* open a new buffer in the same mode
*  insert the characters from the narrowed region linearly in electric
mode (or something that would create newlines in "appropriate" places
for the user's preferred style),
*  indent and fontify that buffer in some way so the indentation of
the first line is consistent with the indentation of the last line
(e.g. if the narrowed region is a series of '}' in CC mode, the first
"}" should be indented to reflect the level implied by the number of
"}"s therein - if necessary by inserting leading matching delimiters
in the reverse order)
*  copy the fontification back to the region in the original buffer

Or to do something equivalent to that without actually opening the
additional buffer.  This method would have the advantage of being
entirely local.

Of course, as a user, I would like to have a command that lets me take
a point that I *know* the correct syntactic classification of, and
specify that from a menu, then have the mode fontify with the
constraint that my assertion is held constant, at least until there is
a modification at the point I made the assertion.

Lynn