Point editors to this tree-sitter

[nobodywasishere]

• helix: https://helix-editor.com/
  • https://github.com/helix-editor/helix/blob/89a7cde2f05fbf2eae212d9301301a8377432be5/languages.toml#L579
• neovim: https://neovim.io/
  • https://github.com/nvim-treesitter/nvim-treesitter/blob/2a496fa4e89034014dd054f04c061ba7d6023a0c/lua/nvim-treesitter/parsers.lua#L1952
• zed: https://zed.dev/
  • https://github.com/crystal-lang-tools/zed-crystal/tree/nobody/crystal-tree-sitter
• vscode
  • TBD

[hugopl]

I was looking if these editors use the same set of captures for highlighting, but seems they don't.

Zed uses https://zed.dev/docs/extensions/languages#syntax-highlighting
NVim uses https://neovim.io/doc/user/treesitter.html#treesitter-highlight-groups
Helix uses https://docs.helix-editor.com/themes.html#scopes

Seems that nvim tried to use the same groups used in Helix.

Considering that nvim-tree-sitter require the queries to be in their repository, and Zed includes the supported parsers in their own repository https://github.com/zed-industries/zed/tree/c57cc35b030407a6e4e9f9cd990135dcdcf36e9e/crates/languages. What highlighting query format should we keep here in the repository?

tree-sitter highlight --check file.cr inform some errors:

Non-standard highlight captures detected:
* function.method.builtin
* keyword.return
* keyword.conditional
* keyword.exception
* string.regex
* type.definition
* function.method
* function.call

Probably because it checks the same captures used by Zed, since the tree-sitter guy is one of the founders.

So I think we should keep the Zed format here in the repository and move the nvim format to nvim-tree-sitter. What do you guys think?

[nobodywasishere]

Trying to get this working with helix, running into an issue where helix segfaults and I have no idea why. Created an upstream issue to hopefully get feedback to try and figure this out. Could be something wrong with this repo, or with how helix is building it.

helix-editor/helix#12257

[nobodywasishere]

So I think we should keep the Zed format here in the repository and move the nvim format to nvim-tree-sitter. What do you guys think?

Could we keep all of them here and dup to their respective repos when changes are made? queries/zed/..., queries/helix/..., etc.

[keidax]

This is a neat idea: https://github.com/tree-sitter/tree-sitter-scala/blob/68773dfed7fee05b3549aaf52ebf8be7c7fe7d5f/.github/workflows/ci.yml#L126-L145

We could use Github actions to check for queries in other repos drifting out of sync

[hugopl]

Now that I'm on a computer I checked the captures used by nvim and tree-sitter, they are the same 🎉

The tree-sitter ones:
https://github.com/nvim-treesitter/nvim-treesitter/blob/master/CONTRIBUTING.md
Nvim ones:
https://neovim.io/doc/user/treesitter.html#treesitter-highlight-groups
Zed ones:
https://zed.dev/docs/extensions/languages#syntax-highlighting

All the same.

TL;DR;
We can put all queries here!

[nobodywasishere]

I'm still not sure we can re-use the same ones for every editor, at least not for helix, due to difference in query precedence rules:

https://docs.helix-editor.com/guides/adding_languages.html#queries

In Helix, the first matching query takes precedence when evaluating queries, which is different from other editors such as Neovim where the last matching query supersedes the ones before it. See this issue for an example.

[hugopl]

I think we can consider both the same until some Helix user complain 😅 , but try to avoid multiple queries match the same node seems like a good practice to me.

[hugopl]

On going nvim-treesitter/nvim-treesitter#7481

[clason]

I'm still not sure we can re-use the same ones for every editor, at least not for helix, due to difference in query precedence rules:

For us, the value of tracked queries is as a reference -- it is much easier to see what changes need to be made to adapt to breaking parser changes if you've made similar changes already. (This also means that these queries are worthless if they're not covered by CI that is run on every PR.) Things like capture names or predicates are trivial customizations on top of that, so I wouldn't worry too much about those; they're basically "somebody else's problem".

Regarding precedence: Helix is the odd man out; the official precedence is "last match wins", i.e., Neovim rules. (They have a PR up to switch, but it's going slooooowly.)

[keidax]

@clason I assume you're referring to the highlight support in tree-sitter test? https://tree-sitter.github.io/tree-sitter/syntax-highlighting#unit-testing

@hugopl I think this is the official list of tree-sitter highlight groups: https://github.com/tree-sitter/tree-sitter/blob/master/highlight/src/lib.rs#L28

[clason]

I assume you're referring to the highlight support in tree-sitter test?

Not really; I don't use the upstream crates. I just mean it's important to keep the queries compatible with the grammar. (I use https://github.com/nvim-treesitter/nvim-treesitter/blob/main/scripts/check-queries.lua for that, of course, but as long as you can check that the queries don't refer to removed or renamed nodes, any way will do.)

[hugopl]

The linter in nvim-treesitter already found some issues that I fixed in the PR but not here, I'll do that once I have time.