GNU bug report logs -
#64647
treesit-query-error due to a recent change to tree-sitter-javascript grammar definition
Previous Next
Full log
View this message in rfc822 format
In data domenica 16 luglio 2023 10:38:37 CEST, Theodor Thornhill ha scritto:
> Eli Zaretskii <eliz <at> 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
This bug report was last modified 2 years and 17 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.