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

[Dmitry Gutov]

On 26/03/2023 08:04, Eli Zaretskii wrote:
> > Date: Sun, 26 Mar 2023 00:57:22 +0200
> > Cc: wkirschbaum@gmail.com, casouri@gmail.com, 62333@debbugs.gnu.org
> > From: Dmitry Gutov <dgutov@yandex.ru>
> >
> > > How does that work with features such as font-lock, which do widen?
> >
> > Using font-lock-dont-widen.
>
> That's only for font-lock.  Parsing was not on the table when that was
> introduced, so it doesn't have a similar mechanism.

Parsing is on-demand, by font-lock and other features.

> > We've had this discussion several times over by now. Should it be
> > documented somewhere?
>
> Probably, but that's a tangent.
>
> > > Anyway, isn't this discussion a bit premature, as no TS mode has been
> > > used with the mmm framework yet?
> >
> > There is no reason to assume that: the combinations of modes are just a
> > matter of user configuration. And so far it should be working okay.
>
> Again, I'm talking about using a parser library.  We may need to
> introduce a way of limiting the parser to a certain range of buffer
> text positions, independently of narrowing.

Except it's already limited by narrowing.

> As we all know, narrowing
> is a problematic feature to use in Lisp programs, so maybe we should
> do this better in the case of parsers.  Then problems like this one
> could be solved more cleanly and simply.

Narrowing problematic to use in Lisp?

> > And anyway, I like I mentioned, this will break this common pattern as well:
> >
> >     (save-restriction
> >       (narrow-to-region ... some-limit-position)
> >       (forward-sexp))
> >
> > I've used it in ruby-syntax-propertize-percent-literal, for example.
> > Except with 'forward-list' rather than 'forward-sexp', but others can
> > use the latter.
>
> You want to repeat all the arguments we already brought up?

You might choose to ignore a third-party mode, but breaking a common 
pattern seems more dangerous.