elixir-lang / tree-sitter-elixir

Elixir grammar for tree-sitter
https://elixir-lang.org/tree-sitter-elixir
Apache License 2.0
245 stars 24 forks source link

Capture group for module names #38

Closed andrhua closed 2 years ago

andrhua commented 2 years ago

Not sure where to ask this, but let's start small.

Here https://github.com/elixir-lang/tree-sitter-elixir/pull/16 modules were given @module capture group. IIUC that was done basically to cater Github TS highlighter, which somehow has color for @module but not for @type. Again, correct me if I'm wrong, nothing really stops, for example, proprietary IDE's TS plugin to recognize only @class as capture group for classes, namespaces, modules etc. At the same time, nvim-treesitter could recognize only @namespace as capture group for the same entites.

tree-sitter docs to me reads like you're entitled to have arbitrary capture groups, which is kinda reasonable, given that each language has its own set of entities. So there's no fixed set of capture group names for related entities, and I don't know whether there might be any consensus at all?

the-mikedavis commented 2 years ago

Yes: which captures to use are arbitrary for any tree-sitter consumer (editors, difftastic, tree-sitter-cli, GitHub, etc). Typically a consumer will map the name of a capture to some color. For example, tree-sitter-cli maps capture names to a terminal 256-color https://github.com/tree-sitter/tree-sitter/blob/3739b7794e381582c8f4a37b2ccec756c3504984/cli/src/highlight.rs#L145-L177.

Different consumers may have different conventions. I know nvim and helix use @namespace for modules but github and tree-sitter-cli use @module

jonatanklosko commented 2 years ago

Also note that we do provide highlight captures as part of this repo and it is used by GitHub, so we try to keep it in line with GitHub and tree-sitter-cli. The consumer can define their own captures to define whatever groups and names they see fit (e.g. nvim-treesitter) :)

andrhua commented 2 years ago

ok thx guys, I'll use :TSEditQueryUserAfter then