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

From: Theodor Thornhill <[email-masked]>
Date: Sat, 15 Jul 2023 19:54:03 +0200

Eli Zaretskii <[email-masked]> writes:

>> From: Vincenzo Pupillo <[email-masked]>
>> 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?

Thanks,
Theo