Recursive nodes are difficult to match in queries

[tmillr]

Is it at all possible for recursive nodes such as dot_index_expression and method_index_expression to be changed to be sequential?

Currently, there doesn't appear to be a way to captures nodes recursively (only sequentially with * and +) in treesitter queries, leading to having to resort to queries with "manual" recursion up to a "limited" depth like the following: https://github.com/projekt0n/github-nvim-theme/pull/250/files

For example, since dot_index_expression nodes currently nest recursively when multiple instances of them appear side-by-side in the code, it is not possible to capture any of its child nodes beyond the 1st level without resorting to such manual recursion as shown in the link above, whereas if they were sequential, I could simply use tresitter's + or * repetitions/quantifiers to distinctively capture these nodes, and their non-recursive children, up to arbitrary lengths.

-- E.g. in a query, how could I capture all "." nodes appearing within a
--`dot_index_expression` that are themselves within `function_declaration` names?
function tbl.x.y.z() end
function tbl.x.y:z() end
-- etc.

Is there a good reason why they are recursive? Is it only so that multiple of them can fit under a single ts field?

Unfortunately, I imagine this would be a breaking change, if it even can be changed.

Also see

• Specify descendant or ancestor in query tree-sitter/tree-sitter#880
• fix: lua function declaration name highlighting projekt0n/github-nvim-theme#250

[MunifTanjim]

Is there a good reason why they are recursive?

That's the structure that conveys their meaning well. Many other languages does the same thing, e.g. ecma (javascript, typescript), go, python, rust, most others.

---

This seems like a limitation of the query language. So I think tree-sitter/tree-sitter#880 is actually the right place to raise it.