bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes

[Dmitry Gutov]

On 28/03/2023 14:38, Eli Zaretskii wrote:
> > Date: Tue, 28 Mar 2023 02:33:38 +0300
> > Cc: wkirschbaum@gmail.com, casouri@gmail.com, 62333@debbugs.gnu.org
> > From: Dmitry Gutov <dgutov@yandex.ru>
> >
> > > With parser-based features, we have an opportunity to do this in a
> > > cleaner manner.
> >
> > parser-based features don't need this at all, if considered in
> > isolation. But if we try to combine them with existing mode, or existing
> > packages, they need to play by the common rules. Which they currently do.
>
> Sorry, I don't see the relevance of that to what I wrote above.
>
> > > > If we take indent-for-tab-command, for example, it doesn't have such a
> > > > variable, and doesn't really need to: the top-level command calls
> > > > 'widen', and then indent-line-function (set by major mode and altered by
> > > > e.g. mmm-mode) is free to impose its specific bounds.
> > >
> > > I thought about a lower-level, infrastructure-level, mechanism that
> > > could be used to restrict a parser to a certain region of the buffer.
> > > Then this could be used by every feature based on parsers, instead of
> > > us having to invent a separate solution for each one.
> >
> > Like narrowing, but just for parsers? But parsers obey narrowing
> > already. Sounds a bit like conceptual duplication. How does this solve
> > blink-matching-paren issue anyway?
>
> We could widen without fearing that a parser will "invade" regions of
> buffer text that we don't want it to wander into.

So any code that wants to restrict a "parser" based buffer, would need 
to use a different primitive to narrow? And vice versa, any code that 
uses a parser, will need to (widen) first, to ensure that the parser is 
not affected by any restriction set up by any code previously?

Anyway, I don't see why we should institute a special category for these 
buffers. Most language modes which define syntax-propertize-function are 
basically "parser-based", in most of the relevant respects. Except the 
accuracy is less, and we write the parsing code ourselves.

> > > > The "grand unified theory of mixed major modes" has been attempted a few
> > > > times in the past, and never reached anything practical.
> > >
> > > But here we have a unique opportunity to maybe find a solution, at
> > > least for stuff based on tree-sitter and similar libraries.  That
> > > maybe not "grand", but certainly "respectable".
> >
> > tree-sitter has its own support for mixed languages.
>
> So your argument about mmm framework was a red herring, cause that
> problem doesn't exist wrt tree-sitter parsers?

Nope, see the first paragraph of my previous reply (the "no relevance" one).

> > > > My stance here is we shouldn't break it before we create a new one.
> > >
> > > No one broke anything.  We are just discussing ideas.  Please don't
> > > exaggerate.
> >
> > I never said anybody has broken anything already.
>
> You did say that my ideas break something, see above.  Ideas cannot
> break any code, so this argument shouldn't be brought up if you want a
> calm and rational discussion.

Ideas cannot, but implementing them can. "This or that change will break 
an existing convention" is a rational argument.

Shall we stop quibbling over words?