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