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

[Theodor Thornhill]

Vincenzo Pupillo <v.pupillo@gmail.com> writes:

> In data sabato 15 luglio 2023 21:16:42 CEST, Eli Zaretskii ha scritto:
>> > From: Theodor Thornhill <theo@thornhill.no>
>> > Cc: Vincenzo Pupillo <v.pupillo@gmail.com>,  Jostein Kjonigsen
>> > 
>> >  <jostein@kjonigsen.net>,  64647@debbugs.gnu.org
>> > 
>> > Date: Sat, 15 Jul 2023 19:54:03 +0200
>> > 
>> > Eli Zaretskii <eliz@gnu.org> writes:
>> > >> The patch in attachment fixes both problems.
>> > > 
>> > > 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.

>> > I don't disagree, but I think this is a difficult problem to solve, but
>> > with an easy cop-out solution that most other implementors use - just
>> > refer to the last supported commit. We've had some discussions on this,
>> > but IIRC we never settled on anything. Personally, I think a
>> > 
>> > ;;; Tree-sitter-version: bb1f97b643b77fc1f082d621bf533b4b14cf0c30
>> > 
>> > header may be the simplest way to at least signal some awareness
>> > here. That way the auto install mechanism can pull that hash directly
>> > and we can ensure some sort of compatibility checking.
>> > 
>> > What do you think?
>> 
>> 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. 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 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?

Do you want to write such a function Vincenzo?

Theo