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

Closest thing I’ve found is telling vscode .eex is .html. But you lose the .eex syntax highlighting. I’m interested in hearing what others have discovered. I don’t spend a ton of time in .eex files so it hasn’t been too big of a deal for me.

That’s the closest I’ve got, too. Which plugin do you use?

Here’s the results/issues I’ve seen so far:

Prettier:

Won’t parse EEx that contains strings due to the extra double quotes, and so fails to format entirely:

311788×584 83.5 KB

Beautify:

This did format, but had the same double-quote issue with EEx tags that added a \n before the closing quote. Also added a random newline between the closing </script> (although perhaps that’s standard Beautify behaviour?

561348×208 40.1 KB

I have a feeling I cannot possibly have exhausted all the options. Are there any other options I’m overlooking?

Thanks in advance!

I posted an update about the configuration fo beautify to format EEx template as good as possible now. Works quite well now for me.
Have a look at .eex formatting? · Issue #129 · timmhirsens/vscode-elixir · GitHub

I’m curious why VSCode has such issues formatting eex files? In Atom.io a *.html.eex file uses the normal HTML formatter for the file and the Elixir formatter for inside <%...%> parts, it can arbitrarily nest formatters based on various markers (For *.html.eex files the start marker is <% and the end marker is %>, like XML in Scala and PHP in HTML and so forth. Can’t the same thing be done in VSCode as done in Atom.io? Formatting works as expected, syntax coloring works as expected, intellisense works as expected, etc…

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.

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. ^.^

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.

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 ^.^).