bug#64647: treesit-query-error due to a recent change to tree-sitter-javascript grammar definition

[Eli Zaretskii]

> From: Theodor Thornhill <theo@thornhill.no>
> Cc: Eli Zaretskii <eliz@gnu.org>,  64647@debbugs.gnu.org,
>   jostein@kjonigsen.net
> Date: Sat, 15 Jul 2023 22:45:31 +0200
> 
> >> > > Will the patch work with the grammar libraries before the recent
> >> > > change?
> >> > 
> >> > It will introduce regressions, but the patch itself is a change for the
> >> > better, both in emacs land and in the grammar itself.
> >> 
> >> What kinds of regressions?
> >> 
> 
> Because the nodes seems to have been removed/swapped in for new ones, we
> will lose the functionality for people using versions < bb1f97b6.

That's what I thought.  I think we should try to avoid such
regressions if it's feasible.

> >> I think what I wrote: that we should try to make our modes work with
> >> reasonably old versions of the grammars, if that is practical.  While
> >> in general it could be a very difficult, if not impossible, to achieve
> >> that, the question is whether this particular issue can be solved in
> >> that manner.  If it can, we should do it.
> 
> Yeah, I think we can do that in this case. I'm just wondering whether
> it's worth the effort or not.

AFAIU, people tend to have old grammar libraries all the time.  For
example, we had a couple of bug reports for C or C++ which turned out
to be due to grammar libraries that are not the latest HEAD of their
respective repositories.  Some people tend to use only official
releases of those grammar libraries (for those which make releases;
many don't).  Also, you cannot upgrade the library while the Emacs
session which uses it is running, so people who have long-running
sessions and don't like to restart Emacs sometimes have no choice but
to stay with an old library for some time.

For these and other reasons, I think being less rigid in requiring the
latest grammar libraries will benefit our users.

> Should we introduce some notion of
> "deprecated" tree sitter functionalities? Otherwise I guess we'll have
> to maintain a growing set of compat-code, which over time will incur a
> performance cost, and it may be difficult to remember what code is
> compat-code and what isn't. 

I'm not afraid of compatibility code, as long as it's manageable.  We
could retire some of that as time passes.  But we are not yet at a
point where this compatibility code presents any significant issue, so
I'd rather we delayed the decision until we come to that bridge.

1> > I can rewrite both patches in the same way I had patched java-ts-mode. 
> > Basically, there are only two changes. I think it would be useful to have a 
> > function to check whether grammar features are supported or not. For 
> > example, 
> > a specialized version of treesit-query-validate that could also be used in 
> > interactive mode (to simplify the development).
> >
> > Do I rewrite the patches?
> 
> I seem to have missed the java-ts-mode patch. Where is it? Do you have
> such an implementation ready at hand? To me it sounds smart to have such
> a function, and it sounds like it should be in treesit.el, but that
> would probably be too late for emacs-29, I think?

A function will probably go to master, but an ad-hoc compatibility fix
that doesn't regress for older grammar libraries would be welcome on
emacs-29 (assuming it is not very complicated).

Thanks.