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

Comments highlighting / parsing #31

Open
paulhenri opened this issue Mar 23, 2023 · 7 comments
Open

Comments highlighting / parsing #31

paulhenri opened this issue Mar 23, 2023 · 7 comments

Comments

@paulhenri
Copy link

Hi,
The following issue occurs with neovim, i can't speak for other editors.

We have issues when using this form of comments <% # Some comment %> instead of this form <%# Some comment %>
If we pass on the comment line every following lines are seens as a comment (See picture below)
image

We tried to tweak to the parser to handle this case by changing the _hash_comment function like so :

_hash_comment: ($) => seq(/<%[\s]*#/, prec.left(seq(repeat($._code), "%>"))),

Parsing tests do work fine with this function, even with changed cases to reflect the change but highlights one do not :

Error in query file "highlights.scm"
Caused by:
    Query error at 11:4. Invalid node type

We are willing to make a Pull request to change this behavior once it works we are just looking for some hints or direction to solve the problem.

@the-mikedavis
Copy link
Member

I can't reproduce this in Helix so I think this may be an issue with the nvim-treesitter queries or the version of the parser it is using.

That error comes from this line in the queries: once _hash_comment no longer uses a literal "<%#" token, tree-sitter's query analysis will say that the <%# node is not a valid node type to query for.

I think that adding extra space at the beginning is not a robust fix though - I suspect that the same problem would happen if you had comments after code like <%= gettext(..) # comment %>.

@paulhenri
Copy link
Author

The problem is clearly with nvim-treetsitter or i would think so ; I tried to use helix queries or even the one provided here, elixir code is simply not highlighted anymore.

I am gonna dig more and get more informations. Thank you for you input.

Paul-H

@SichangHe
Copy link

Screen Shot

Is this related? Also on Neovim.

@paulhenri
Copy link
Author

To me it is, the colorisation has various problem but nvim-treesitter uses its own set of queries and even some that are not here so... To be honest i don't know how to approach this right now and every attempts i have made have been unsuccessful.

@connorlay
Copy link
Member

The difference between <%# and <% # is how they are parsed: the first version is a HEEx comment, while the second version is a HEEx directive. HEEx directives allow for interpolation of arbitrary Elixir code into your HEEx code. In other words, <%# a comment %> is parsed and highlighted using just the HEEx grammar, while <% # a comment %> is parsed and highlighted using both the HEEx grammar and the Elixir grammar.

Each editor that uses tree-sitter defines its own set of captures and highlighting logic. Given this is not reproducible in Helix, I think this is an issue specific to nvim-treesitter and not with tree-sitter-heex itself.

@paulhenri I suggest opening an issue in nvim-treesitter as that is likely where the fix will have to be made.

@SichangHe
Copy link

As an aside, is it worth it to move to Helix for Phoenix development? Thanks.

@the-mikedavis
Copy link
Member

I can't reproduce those highlighting bugs in Helix @SichangHe. I think that neovim might be behind on the version of this parser or there might be something odd happening with the injection queries.

I'm definitely biased since I work on Helix but I think it's a nice choice for working in an Elixir and/or Phoenix codebase. I believe it should be possible to highlight these snippets correctly in nvim too though.

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

4 participants