bug#65234: [PATCH] Fix jsx font-lock in older tree-sitter-js grammars

[Eli Zaretskii <eliz@gnu.org>]

> Cc: Vincenzo Pupillo <v.pupillo@gmail.com>,
>  Daniel Colascione <dancol@dancol.org>
> Date: Fri, 11 Aug 2023 17:18:32 -0400
> From:  Danny Freeman via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> I have a patch to fix a bug I found in js-ts-mode.
> 
> Description of Problem:
> A new function was wrtiten to account for a breaking change in the
> tree-sitter-javascript grammar, see [0]
> 
> This function returns some tree-sitter queries used by the js-ts-mode
> font lock settings.
> 
> We attempted to check for the breaking change by running a query
> (treesit-query-capture 'javascript '((member_expression) @capture))
> which would in theory fail when an old grammar is being used.
> 
> The problem is that this query does not fail on old grammars, so the
> backwards incompatible font-lock queries are always used. When
> font-locking a JSX file, the queries that look like
> (jsx_opening_element [(member_expression) ...
> throw errors and font locking fails (only on jsx elements).
> 
> Solution:
> Instead of fixing the bb1f97b compatibility check with something like
> 
> (treesit-query-capture 'javascript
>   '((jsx_opening_element (member_expression) @capture)))
> 
> I have opted re-write the font lock rules that capture the same
> nodes by the "name:" field instead of by the specific node names (where
> the backwards incompatible change took place).
> 
> The possible nodes that can be in the "name" field: 
> After [1]: "identifier" "member_expression" "jsx_namespace_name"
> Before [2]: "identifier" "nested_identifier" "jsx_namespace_name"
> 
> "jsx_namespace_name" is an additional node captured by these rules. As
> an example, in the JSX expression
> 
> <Foo:bar/>
> 
> "Foo:bar" is a node of type "jsx_namespace_name" and would be captured
> with @font-lock-function-call-face, where before this change it was not
> captured or highlighted at all. If there is a reason this should not be
> captured and highlighted, a new query can be added in to capture these
> nodes first with @default so they are not highlighted like before.
> 
> Some thoughts:
> These backwards incompatible grammar changes are rough to deal with, but
> I'm glad they are taken into account. I use nixos, and the current
> stable version 23.05 packages the older version of the JS grammar for
> emacs which is how I noticed this. I wish the developers of the js
> grammar were more careful about backwards compatible changes. The fact
> that they were renaming a node without much reason didn't seem to bother
> any of the maintainers.

Yuan, Theo: any comments on this?  Is this safe enough to go into the
emacs-29 branch?

Thanks.