-
Notifications
You must be signed in to change notification settings - Fork 11
Highlight field expression in types #28
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
base: main
Are you sure you want to change the base?
Highlight field expression in types #28
Conversation
It seems impossible to match a recursive expression tree-sitter-grammars/tree-sitter-lua#24. |
Thanks for your PR! I agree that should be improved. Would you mind making this PR upstream at tree-sitter-julia? We track their reference queries which makes it easier to update the grammar and maintain our repo. Also, this would benefit other projects like neovim that use the grammar. Let's keep this draft open to track the progress on this issue. |
In the upstream issue, it's said that the preferred solution is document highlight by language server, but given the current situation where there is no LS that performs such highlighting, I think it would be better to merge this PR? It's quite possible that I will add such highlighting to the LS I'm currently developing in the future, but it's not a current priority. |
From tree-sitter/tree-sitter-julia#165 (comment):
I'm not sure we wouldn't break something else... |
Oh, I missed that part. If there's a possibility that something could break, we shouldn't rush to merge. |
Hey,
I'm using zed for a while and love to write Julia code with this editor.
However, when I write something like
x::Module.T
, the typeModule.T
is not highlighted and it's annoying.So I took the evening off to understand how tree sitter and the highlight.
Here is a suggestion for fixing a part of the bug.
You see the difference before and after with the two following screenshots.
before


after
As you can see I could not make it recursive because I could not find a way to give the
@type
tag priority over the@variable.member
tag. The most specific match seems to take precedence.It's far from perfect but it improves the current behavior and I guess
Module.SubModule.T
is enough for 80% of users.I'm opening it as a draft PR because somebody here might have the solution.