select one of many capture groups

[SephVelut]

enum Thing {
    A(u8),
    B(u8)
}

module1::module2::Thing::A(0);

The A in Thing::A is recognized by the rust treesitter parser as
@variable
@type
@function
@type
@constant

The highlight for @constant is chosen for A. How do I highlight A as a @type?

nvim-treesitter: require("nvim-treesitter.health").check()

Installation ~
- OK `tree-sitter` found 0.21.0 (parser generator, only needed for :TSInstallFromGrammar)
- OK `node` found v21.6.2 (only needed for :TSInstallFromGrammar)
- OK `git` executable found.
- OK `cc` executable found. Selected from { vim.NIL, "cc", "gcc", "clang", "cl", "zig" }
  Version: cc (GCC) 13.2.1 20230801
- OK Neovim was compiled with tree-sitter runtime ABI version 14 (required >=13). Parsers must be compatible with runtime ABI.

OS Info:
{
  machine = "x86_64",
  release = "6.7.5-arch1-1",
  sysname = "Linux",
  version = "#1 SMP PREEMPT_DYNAMIC Sat, 17 Feb 2024 14:02:33 +0000"
} ~

Parser/Features         H L F I J
  - bash                ✓ ✓ ✓ . ✓
  - c                   ✓ ✓ ✓ ✓ ✓
  - cpp                 ✓ ✓ ✓ ✓ ✓
  - diff                ✓ . . . .
  - git_rebase          ✓ . . . ✓
  - gitcommit           ✓ . . . ✓
  - gitignore           ✓ . . . .
  - go                  ✓ ✓ ✓ ✓ ✓
  - html                ✓ ✓ ✓ ✓ ✓
  - javascript          ✓ ✓ ✓ ✓ ✓
  - json                ✓ ✓ ✓ ✓ .
  - lua                 ✓ ✓ ✓ ✓ ✓
  - markdown            ✓ . ✓ ✓ ✓
  - markdown_inline     ✓ . . . ✓
  - meson               ✓ . ✓ ✓ ✓
  - pem                 ✓ . ✓ . ✓
  - proto               ✓ . ✓ . .
  - python              ✓ ✓ ✓ ✓ ✓
  - query               ✓ ✓ ✓ ✓ ✓
  - ruby                ✓ ✓ ✓ ✓ ✓
  - rust                ✓ ✓ ✓ ✓ ✓
  - toml                ✓ ✓ ✓ ✓ ✓
  - vim                 ✓ ✓ ✓ . ✓
  - vimdoc              ✓ . . . ✓

NVIM v0.10.0-dev-2427+geb4783fb6c
Build type: RelWithDebInfo
LuaJIT 2.1.1702233742
Run "nvim -V1 -v" for more info

[clason]

Write your own query and capture the node as @type. The parser does not recognize these; it parses "nodes" which a query then assigns to a "capture". Use :InspectTree to see the nodes from the parser and :Inspect to see the captures from the query.

Please read the documentation (in Neovim and tree-sitter).

[clason]

No need to get worked up over arbitrary descriptions

I am sorry, but if we don't establish meaningful terminology, there's no I can explain anything to you. In any case, you have your answer (the parser can't distinguish them; you need to write a custom query for this using #eq? or #lua-match?), and from now on you're on your own.

[SephVelut]

If you're such a baby that you need to be rude because you want to control how someone describes an innocuous thing, then you are a crazy person.

[amaanq]

no one's gonna bother to help you if you can't even bother to learn how tree-sitter somewhat works (including its terminology). you describing it as something its not is confusing at best, and combative at worst. you're also unnecessarily rude - good luck!

[SephVelut]

Just so it's clear, this is what I said that triggered the maintainer to start being rude.

The Rust parser must be doing something else to give module1::Type the label @type

This isn't about misunderstanding terminology. @clason understood perfectly what label meant when they precisely interpreted it. Their comments of

Again, the parser is NOT giving anything a "label".
I am sorry, but if we don't establish meaningful terminology, there's no I can explain anything to you.
and from now on you're on your own.

is little more than strange controlling behavior stemming from impotent rage. Pretending to be the indignant ones and threatening to not provide technical aid is not going to work with grown adults. You and your buddy need to ditch the snotty attitude and recognize that no one cares about your little repo enough to take abusive treatment for the crime of not using your special important terminology. Covering for your co-maintainer's crappy behavior is schoolyard antics. Grow up.

[clason]

If you took the time to actually read my comments, you would see that you're missing the point: it's not about the terminology per se (although that helps you understand what's going on) but about who is doing what: the parser is not responsible for the "label"; it's the query. If you don't understand that, you have no chance of achieving what you asked us about.

And with that, I hope you can get it sorted out, since you're blocked from this organization.