The very basics... auto-formatting in .eex

That’s really nice, I didn’t know that Atom could do that.

AFAICT, only one ‘beautifier’ can be activated per file type in VSCode. I could be wrong, but I haven’t seen any settings to the contrary.

1 Like

That sounds like a really bad misdesign if so… Even the ancient vim and emacs have primary buffer types and sub buffer types (that Atom.io modeled after from what I’d guess). A single file type may not have just a single ‘language’ in it, so that seems really bad design… o.O

I tried using VSCode for a bit, and although I like that the elixir plugin shows specs in it (and I’m wondering why it doesn’t show it in Atom.io even though its the same author when Atom.io absolutely can do the same thing), it was lacking so many plugins that just make my life so much easier that are just common in Atom.io and EMacs both (I use both quite routinely, depending on if I’m in a GUI or console system). It’s ecosystem just seems really young and incomplete in comparison. Atom.io used to be a huge amount slower than VSCode but that’s been fixed for well over a year now as well to any factor that I could tell the difference between (they went through a big performance push for like a year there).

I’d really say give Atom.io a try, though I really hope that @specs display from the elixir-ls plugin gets added someday. ^.^

2 Likes

Did you ever compare Atom and Sublime Text 3 by the way?

Thank you! I’ve switched from Prettier to Beautify in VSCode using your settings and finally I have proper formatting inside .eex files.

1 Like

You’re welcome. Glad to hear that I could help.
If you notice anything wrong, please let me know.

I’ve barely ever looked into sublime text actually… ^.^;

I’m a bit particular about certain features that I really have to have to ‘feel’ productive. Proper intellisense is a big one (I’m still unhappy here with this for Elixir with elixir-ls, but that’s mostly because of Elixir the language, statically typed languages are far far superior here). Context sensitive syntax coloring (like the syntax coloring of these forums or VSCode on Elixir are just bad, like horribly bad, even Atom and emacs emulate this well enough to be indistinguishable from proper context sensitive syntax coloring in a ‘real’ IDE like KDevelop). Fast responsiveness (elixir-ls’s plugins in both atom and vscode is super slow here compared to what I’m used to for other languages and it bugs me to no end). Among a few other minor ones (git interactions and blame displaying, etc… etc… but atom, vscode, emacs, etc… all do this very well, etc…).

Oh, and it really must support embedded types within other files, like how both emacs and atom can do but vscode can’t, where you can get html in one context, eex, in another, and php in yet another, all in the same file. It’s amazing how often this is used (like a super-often example is markdown documents, which contains code highlighting for potentially dozens of languages in the same file, and those code blocks can contain ‘different’ code inside those blocks, like having elixir inside html inside markdown inside elixir doc blocks ^.^).

It all depends on the plugin.
As youknow,all these plugins are developped by simple independant developpers so it’s normal to find bugs.
No plugin is proviedby Microsoft.

That is if they are to handle sub-context support manually, but that is something that should be handled by the editor backend itself though.

1 Like

Atom ships with Tree-sitter now, which understands your code semantically rather than pretend to with regex (TextMate grammar). Syntax highlighting and auto-formatting embedded languages would theoretically be far superior.

There are no Tree-sitter parsers implemented for Elixir or EEx yet. But since VS Code hasn’t indicated support, developer experience on Atom may pull ahead once a parser is made.

2 Likes

That’s not really directly related to auto formatting, but I think here is a good place to publish this.
When you use vscode-elixir it really drove me crazy how commenting on interpolated elixir tags inside an .html.eex file broke through the complete syntax code.
So I just opened a PR to vscode-elixir that solves that problem by simple using the normal html multiline comment tags.
https://github.com/fr1zle/vscode-elixir/pull/146

2 Likes

VS Code does support embedded languages: https://code.visualstudio.com/api/language-extensions/syntax-highlight-guide#embedded-languages

1 Like

Ooo nice! It’s about time it does! I hope extensions take advantage of it without users needing to do manual configuration like that! :slight_smile:

I’ve been trying to modify the vscode-elixir-ls to use it all night, but no luck so far, if anyone knows of other extensions that take advantage of that feature let us know it’ll be helpful to see some examples. (I tried to mimic what Ruby extension does but didn’t work out very well)

1 Like

ping…

Yes, this is also driving me mad about the EEX formatting in VSCode.

I also found the embedded language support instructions and tried to figure out what was needed to support vscode-elixir-ls, but couldn’t figure it out…

Did you raise a bug on this with vscode-elixir-ls? Perhaps someone there has more idea?

2 Likes

For VSCode, I use the Prettier plugin for most filetypes but as stated earlier in this thread that breaks .html.eex files.

What I found works great is to install the Beautify plugin and configure it to only affect EEx:

  "beautify.language": {
    "js": [],
    "css": [],
    "html": [
      "HTML (EEx)"
    ]
  }

If you are using ST3 you’ll want to use the HTML-CSS-JS Prettify plugin.

I still haven’t figured out how to get syntax highlighting or auto-formatting to apply to inline LiveView as the ~L sigil is treated as a normal heredoc string.

Hope this helps someone!

4 Likes

I have created this pull request:

But it does not work just as you expect, the beautify solution should be the best option available at the moment

In settings.json, instead of setting "files.associations": { *.html.EEx: ... } to "HTML", set it to "HTML (EEx)":

"files.associations": {
    "*.js": "javascript",
    "*.ex": "elixir",
    "*.exs": "elixir",
    "*.eex": "EEx",
    "*.html.EEx": "HTML (EEx)"
},

I just stumbled onto this, and @tme_317 has already found it, but you don’t need Beautify.

Once files.associations for .html.eex are set to “HTML (EEx)” it appears that .eex work as an embedded language inside of .html, so they both work seamlessly. Snippets extensions work, .eex tags autocomplete, intellisense and syntax highlighting work, it’s all back.

7 Likes

That’s great! Your solution along with @tme_317’s works well. The one thing that seems to be lacking is a way to respect indentation with embedded code. For example, the values inside of for should be indented, but when I format, everything inside of it are all moved to the same level of indentation as the for. This applies to all constructs, like if and do.

Do you or anyone else know of any way out of this?

If not, no worry. Being able to format at all helps more with development speed than the extra readability of properly formatted elixir parts. It would be nice though :slight_smile:

That’s a good point and I don’t yet have an answer. I checked in emacs and of course it works there (though I have other emacs problems, which is why I usually shrug and open VS Code…).

I added to an open issue here: https://github.com/fr1zle/vscode-elixir/issues/129

FWIW, a potentially straight-forward solution to this is to get an existing embedded language, such as PHP or Ruby’s ERB, duplicate its configuration file and then changing the embedded language to Elixir.

I did this on Sublime Text, copying from Ruby’s ERB, and it was relatively easy and it works quite well.

7 Likes