bug: highlight of types prefixed by modules

[guimarqu]

Did you check existing issues?

• I have read all the tree-sitter docs if it relates to using the parser
• I have searched the existing issues of tree-sitter-julia

Tree-Sitter CLI Version, if relevant (output of tree-sitter --version)

No response

Describe the bug

Hi,

I mainly work with Zed and have quite an annoying highlight bug with types prefixed by modules.

I suggested a change in the julia-zed repo to fix the bug in 80% of cases with a full description and examples: JuliaEditorSupport/zed-julia#28 (comment)

I think there is another option to fix the bug. We could change the parser by introducing a new node for "field expression inside types".

For instance instead of having :

variable::MyModule.T
          ---- field expression ----

we could have :

variable::MyModule.T
          ---- scope expression ----

and it would make the highlight query much easier.

I would be very happy to contribute by either :
1- changing the highlight query to capture MyModule as a module and T as a type in the MyModule.T expression (see PR JuliaEditorSupport/zed-julia#28)
2- suggest a change in the parser to capture children of scope_expression as a type and avoid very large capture expressions.

Option 1 is a quick win for 80% of cases but quite verbose.
Option 2 requires more work (I'm not familiar with the tool).

Steps To Reproduce/Bad Parse Tree

This is not a bad parse tree. This is about highlighting.

Expected Behavior/Parse Tree

Capture MyModule.MySubModule.[...].T as a type.

Repro

No response

[guimarqu]

We could use scoped_identifier instead of introducing a new node.

[savq]

As they're written, the queries in the zed PR will match any field access. not just modules.

That's kinda the problem. Modules are regular values and there's no way to distinguish them syntactically. You'd have to use something like lsp semantic tokens to highlight them properly.

The easiest way to have something somewhat good would probably be using a #match? predicate.

We could change the parser by introducing a new node for "field expression inside types".

We cannot do that. These rules-that-are-parsed-the-same-but-named-differently are costly. We already have a very bloated parser, and we're trying to make it simpler, not more complicated.