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:

> Hi Theo,
>
> In data sabato 15 luglio 2023 19:54:03 CEST, Theodor Thornhill ha scritto:
>> Eli Zaretskii <eliz@gnu.org> writes:
>> >> From: Vincenzo Pupillo <v.pupillo@gmail.com>
>> >> Date: Sat, 15 Jul 2023 14:34:29 +0200
>> >> 
>> >> this commit (bb1f97b643b77fc1f082d621bf533b4b14cf0c30) changed the
>> >> definition of the JSX grammar to tree-sitter-javascript. This causes a
>> >> node type error: "
>> >> Error while displaying: (jit-lock-function 1) reported
>> >> (treesit-query-error
>> >> "Node type error at" 24 "(jsx_opening_element [(nested_identifier
>> >> (identifier)) (identifier)] @font-lock-function-call-face)
>> >> (jsx_closing_element
>> >> [(nested_identifier (identifier)) (identifier)] @font-
>> >> lock-function-call-face) (jsx_self_closing_element [(nested_identifier
>> >> (identifier)) (identifier)] @font- lock-function-call-face)
>> >> (jsx_attribute (property_identifier) @font-lock- constant-face)" "Debug
>> >> the query with `treesit-query-validate'")
>> >> "
>> >> Indentation also has problems due to the deletion of "jsx_fragment"
>> >> definition.
>> >> 
>> >> 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.
>> 
>> >> p.s. nvim-treesitter tries to limit these problems by indicating which
>> >> commit to install. Does it make sense to try a similar approach with
>> >> emacs as well?> 
>> > I think it is better if we make the code work with as many versions as
>> > possible, by checking whether a feature exists before using it.
>> > 
>> > Theo, Jostein: any comments or ideas?
>> > 
>> > Thanks.
>> 
>> 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?
>> 
>> @Vicenzo, seeing as this change only targets the JSX variant in
>> js-ts-mode, could you possibly also make the according changes to
>> tsx-ts-mode as well?
> Yes, and I also attached the previous one with a corrected commit message ((I 
> had written js-ts-mode.el instead of js.el)
>
> Thanks, 
> Vincenzo

Thanks - the patches looks good to me, but let's see what we end up with
wrt backward-compatibility :)

Theo