Stephan Seitz

Wouldn't i be possible to keep the current API? The iterator could yield the same capture_id multiple times but with different nodes.

@MDeiml maybe we could fix `@combined` in the context of this PR and make it behave like in https://github.com/tree-sitter/tree-sitter/blob/3ff5c19403ccb8e6139a048b3257302a8da6139e/docs/section-4-syntax-highlighting.md#L363-L365 I think we misunderstood what `combined` should mean in the tree-sitter...

@Hrle97 has created patch from @steelsojka old PR that would exclude children from the parent language which is the actual meaning of "combined" in upstream tree-sitter. We could either try...

I think a breaking change wouldn't that bad. In nvim-treesitter we would probably switch to a shim until the next release. If you think it could avoid some pain you...

@vigoux but I wonder whether then all_captures should then be the only option to make people think that for the same match there might be multiple arrangements. `all_captures = false`...

Probably not an issue, but can we still check whether there is any perf-delta due to this change? There will be more matches and also more table creations for `nodes`....

Will there be only one match for `(comment)+ @comment` with multiple nodes or every combination of `(comment)+` that fits the description one or more node?

I don't know whether it is worth to use a different symbol just for loading the parser. Ideally, one would use also use the different name to separate the queries...

Isn't there a risk that an implementation of `vim.ui.input` is not aware of `secret = true` when implementing this as compatible change?

The code base for language tree is also very complex with a lot of functionality integrated into. When people (including me) wanted to extend some functionality they most likely had...