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

[Eli Zaretskii]

> Date: Wed, 29 Mar 2023 00:19:41 +0300
> Cc: wkirschbaum@gmail.com, casouri@gmail.com, 62333@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> >> 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?

No, the idea is to create the parser with these restrictions to begin
with.

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

No, if the parser is restricted, there should be no need to "widen"
it, at least not in most cases I could think about where a parser
should be restricted to a part of the buffer.

> Anyway, I don't see why we should institute a special category for these 
> buffers.

Because IMO it's cleaner and simpler than using narrowing, and doesn't
suffer from the problems we see in narrowing.

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

Which first paragraph is that?  In what "previous reply" should I look
and where?  (And why couldn't you simply copy that here, to make
following the discussion easier?)

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

I'm "quibbling" over words because your particular selection of words
makes serious discussion nigh impossible.  Not the first time, either.
As soon as there's some disagreement, sooner or later those words
(like "quibbling") come out.  Whether it's because of some attitude or
not, I don't know, but you may wish to reflect on that and perhaps try
to express your disagreements using different words.