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

Add ~H support #193

Closed
wants to merge 1 commit into from
Closed

Conversation

chrismccord
Copy link

The next Phoenix LiveView release supports a new ~H template engine, which deprecates ~L. I've updated the rules to support the new sigil. Thanks!

@chrismccord
Copy link
Author

This only gets us partially there since some of the new ~H syntax engine won't properly syntax highlight the HTML. @msaraiva might have some insights on what it would take to properly highlight and whether it would make sense to add here or as a separate plugin ala Surface

@msaraiva
Copy link
Collaborator

It's probably a good idea to add a separate entry for ~H instead of using the same one as ~L.

Since they have different grammars, it might be harder to provide unified rules for both of them, especially in the tag attributes area. Depending on how the existing grammar for EEx code is defined, it might be easier to just copy the rules from Surface, starting from the tag rule.

The dependent nodes like node-attributes should be copied too but removing #tagged-expression and replacing #interpolation with EEx own syntax rules.

@msaraiva
Copy link
Collaborator

@chrismccord I can take a stab at it after finishing let + form_for for HEEx, unless of course, someone wants to address it before :)

@msaraiva
Copy link
Collaborator

@axelson we're considering having a separate package for the HEEx syntax highlighting feature. We'll still need some small configurations in vscode-elixir-ls but they will be minimal and probably only required to make the extension watch .heex files and maybe some other minor stuff that will be unlikely to change in the near future.

Having the highlighter in a separate project makes it easier for us to maintain syntax changes and release them much faster, as well as avoiding adding more stuff to vscode-elixir-ls that does not belong to elixir core. Since the highlighter does not depend on any feature of the language server, it seems like a reasonable approach.

Do you think this is the way to go? Any downsides you can see besides forcing the user to install an extra package?

@axelson
Copy link
Member

axelson commented Jul 27, 2021

I think that sounds good and I don't see any other downsides besides the extra package 👍

@axelson axelson mentioned this pull request Aug 9, 2021
@axelson axelson closed this in #204 Aug 13, 2021
@cvkmohan
Copy link

Sorry, for posting the question on a closed issue.

  1. Where does formatting heex files belong? Is it in vscode-phoenix package or this package? Or configuring prettier or beautify with file association of html? I personally liked the surface-formatter. Any chance of bringing it in for heex?

@manicat0
Copy link

@axelson @msaraiva checking in on this -- is the plugin discussed here already out? formatting + highlighting inside ~H would be a huge boost!

@lukaszsamson
Copy link
Collaborator

@xnkm8h a PR would be welcome

@axelson
Copy link
Member

axelson commented Dec 19, 2021

@xnkm8h the plugin mentioned is: https://github.com/phoenixframework/vscode-phoenix

And it does support ~H although I haven't personally tried it.

Also I'm hoping that elixir-lang/tree-sitter-elixir#2 will make it easier to integrate ~H support more widely in the elixir editor ecosystem.

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

Successfully merging this pull request may close these issues.

None yet

6 participants