Add user-extensible tree-sitter queries

[ian-h-chamberlain]

A simple first step toward closing #4612, and also helps with #9461 since it allows for user-customizable highlights queries (thus enabling more precise / complex syntax highlights).

If this is accepted, I have a few ideas for followup changes, which may require some discussion with the Zed team to make sure the ideas seem reasonable:

1. Similar to JSON schemas, register some kind of zed://language/queries/... handler to make it easier to see the concatenated query after Zed processes it.

2. Implement something like an (#override!) directive, which could be used in user-defined queries to disable builtin-defined or extension-defined queries. This would be a (very simple) way to offer something like neovim has, since the default behavior is more like neovim's ; extends.

   • Possible future: (#disable! @some.capture) to selectively disable upstream captures. Since everything is getting concatenated into one query together before parsing I think this should be possible?

3. Possible future direction for Support inheriting queries from other languages #8795 would be to implement a (#inherit! "other-language"), although this probably requires a bit more careful design about how it should work.

Release Notes:

• Added the ability to define custom tree-sitter queries to extend builtin/extension queries.

[maxdeviant]

Thank you for the PR, but I don’t think we want this feature.

While it seems quite powerful, it also seems like it would be a support nightmare. As we could get user reports of features not working due to the user having modified the Tree-sitter queries.

The only supported way of providing new Tree-sitter queries is via extensions.

[ian-h-chamberlain]

While it seems quite powerful, it also seems like it would be a support nightmare. As we could get user reports of features not working due to the user having modified the Tree-sitter queries.

Fair enough, that seems reasonable. Thanks for taking a look anyway!

The only supported way of providing new Tree-sitter queries is via extensions.

With this in mind, do you think the right direction for customizing language queries is the inheritance proposed in #8795 instead, as opposed to extending or overriding queries for existing languages? In other words, to "extend" language Foo, the blessed path would look something like:

• Create an extension with a new language Bar
• In Foo's extension config, inherit queries/grammars/LSP from Foo, modifying as desired
• Users can override their editor to associate files with Bar as needed

For power users, they could maintain a "personal" extension to accomplish some of the same customizations that this PR might have made possible.

If this seems like a reasonable approach, I would be interested in working on an implementation of inheriting queries; I have a local proof of concept but there are some challenges to iron out, and I don't want to spend too much time on it if it's unlikely to be accepted.

Thanks again for your time!