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

[Vincenzo Pupillo <v.pupillo@gmail.com>]

In data domenica 16 luglio 2023 10:38:37 CEST, Theodor Thornhill ha scritto:
> Eli Zaretskii <eliz@gnu.org> writes:
> >> 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.
> 
> Sure!
> 
> >> 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.
> 
> Sure - unless Vincenzo wants to tackle it, I can look into creating a
> function for master to check for available features.

 I am not familiar with the internal emacs treesitter binding. I would need 
some time to study it. However, I have seen that there are functions in the 
treesitter library that are not used by the current binding implementation. 
For example: ts_language_field_id_for_name could be useful to check whether a 
symbol is defined or not. 

In my patch for java-ts-mode I used treesit-query-capture to figure out whether 
a symbol was defined or not. Check out the java-ts-mode--string-highlight-
helper function.

> 
> Vincenzo, do you want to add compat-code to emacs-29 and your patches?

Okay. I think I can do it this week. Do I create a new file, like treesitter-
compat.el ?

> I can take care of the in-core function in a separate bug, if that makes
> sense :)
> 
> Theo

Vincenzo