-
Notifications
You must be signed in to change notification settings - Fork 19
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
Comments
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
Is it at all possible for recursive nodes such as
dot_index_expression
andmethod_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/filesFor 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.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
The text was updated successfully, but these errors were encountered: