Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recursive nodes are difficult to match in queries #24

Open
tmillr opened this issue May 11, 2023 · 1 comment
Open

Recursive nodes are difficult to match in queries #24

tmillr opened this issue May 11, 2023 · 1 comment

Comments

@tmillr
Copy link

tmillr commented May 11, 2023

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

@MunifTanjim
Copy link
Collaborator

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.

maxdeviant added a commit to zed-industries/zed that referenced this issue Oct 28, 2024
Release Notes:

- Python: Improved syntax highlighting for type hints.

# Before

![image](https://github.com/user-attachments/assets/876a69ab-a572-4d1b-af99-e6f85f249ea6)

# After

![image](https://github.com/user-attachments/assets/4fb98a9b-bc5d-4799-b535-057047884383)

---
Why manual recursion?
- Due to tree-sitter grammar not supporting recursion in query
(tree-sitter-grammars/tree-sitter-lua#24),
currently only manual recursion is possible (refer to
https://github.com/projekt0n/github-nvim-theme/pull/250/files).

<br/>

Unable to highlight when simple structures appear before complex
structures, example:
```python
def t() -> str | dict[int, dict[int, dict[int, str]]]:
    pass
```
Because complex structures are parsed as `subscript` rather than
`generic_type` by tree-sitter in this case ☹

<br/>

Related:

- #14715
- [Union Type (Python
Doc)](https://docs.python.org/3/library/stdtypes.html#union-type)
- [Type parameter lists (Python
Doc)](https://docs.python.org/3/reference/compound_stmts.html#type-parameter-lists)

---------

Co-authored-by: Marshall Bowers <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants