nvim-treesitter / nvim-treesitter/nvim-treesitter-textobjects
@parameter.inner/outer capture group is too broad?
Nobody has claimed this yet.
- Dominant language
- Tree-sitter Query
- Stars
- 2.8k
- Forks
- 271
- Avg merge
- 8d 8h
- Merged PRs (30d)
- 1
Description
Describe the bug
I expected @parameter.inner/outer to only select parameters, but it seems like it currently way too broad. This happens in rust, js, ts & go. Since this is the exact same behaviour this might be intended, if so why?
I couldn't really find any discussions on what should be counted as parameters and not so thought i would make an issue on it.
In my mind atleast, it would only make sense to only grab actual parameters, the way it's currently setup feels way to broad.
To Reproduce
Rust example:
fn main() {
let y = plus_one(5); // 5 is captured by @parameter
println!("The value of y is: {y}"); // Captured by @parameter
}
fn plus_one(y: i32) -> i32 { // this is the only parameter in our code, & is captured by @parameter
y + 1
}
Ts example:
// In this example every single line is captured by the @parameter capture group
function test(number: number) { // number is the only actual parameter here.
console.log("print number", number)
console.log("not a parameter")
}
test(1)
This also happens in ts & go.
Expected behavior
In my own config i ended up basically using something like this:
Output of :checkhealth nvim-treesitter
nvim-treesitter: require("nvim-treesitter.health").check()
Installation ~
- OK `tree-sitter` found 0.24.3 (bdfe32402e85673bbc693216f0a6ef72c98bb665) (parser generator, only needed for :TSInstallFromGrammar)
- OK `node` found v22.9.0 (only needed for :TSInstallFromGrammar)
- OK `git` executable found.
- OK `cc` executable found. Selected from { vim.NIL, "cc", "gcc", "clang", "cl", "zig" }
Version: cc (GCC) 14.2.1 20240910
- 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.11.1-arch1-1",
sysname = "Linux",
version = "#1 SMP PREEMPT_DYNAMIC Mon, 30 Sep 2024 23:49:50 +0000"
} ~
Parser/Features H L F I J
- bash ✓ ✓ ✓ . ✓
- c ✓ ✓ ✓ ✓ ✓
- css ✓ . ✓ ✓ ✓
- html ✓ ✓ ✓ ✓ ✓
- javascript ✓ ✓ ✓ ✓ ✓
- lua ✓ ✓ ✓ ✓ ✓
- markdown ✓ . ✓ ✓ ✓
- markdown_inline ✓ . . . ✓
- python ✓ ✓ ✓ ✓ ✓
- query ✓ ✓ ✓ ✓ ✓
- rust ✓ ✓ ✓ ✓ ✓
- svelte ✓ ✓ ✓ ✓ ✓
- typescript ✓ ✓ ✓ ✓ ✓
- vim ✓ ✓ ✓ . ✓
- vimdoc ✓ . . . ✓
- vue ✓ . ✓ ✓ ✓
Legend: H[ighlight], L[ocals], F[olds], I[ndents], In[j]ections
+) multiple parsers found, only one will be used
x) errors found in the query, try to run :TSUpdate {lang} ~
Output of nvim --version
NVIM v0.10.2
Build type: RelWithDebInfo
LuaJIT 2.1.1727870382
Run "nvim -V1 -v" for more info
Additional context
Would a PR making @parameters.inner / outer more strict be welcome?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the Rust and TypeScript examples, then trace how the @parameter.inner/outer captures are defined for Rust, JavaScript, TypeScript, and Go. Confirm the intended parameter boundaries with maintainers; done should be a decided, consistent behavior for the reported cases, with coverage if the behavior changes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, javascript, rust, typescript
- Domain
- developer-experience, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100