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

Previous Next

Package: emacs;

Reported by: Vincenzo Pupillo <v.pupillo <at> gmail.com>

Date: Sat, 15 Jul 2023 12:35:02 UTC

Severity: normal

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Theodor Thornhill <theo <at> thornhill.no>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64647 <at> debbugs.gnu.org, v.pupillo <at> gmail.com, jostein <at> kjonigsen.net
Subject: bug#64647: treesit-query-error due to a recent change to tree-sitter-javascript grammar definition
Date: Sun, 16 Jul 2023 10:38:37 +0200
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.

Vincenzo, do you want to add compat-code to emacs-29 and your patches?
I can take care of the in-core function in a separate bug, if that makes
sense :)

Theo




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.