Elixir IDE discussion

True.

The biggest thing I miss from vscode is the integrated terminal. I’ve used a couple for atom but they didn’t feel that great.

That is what credo does. ^.^
I’ve had no performance issues though, but yeah, Credo can eat a core or 6 for a good few seconds on decently sized projects, that is just how credo works.

yeah, I figured it was unrleated to the plugin itself. In upgrading to Phoenix 1.3 from 1.3-RC2 I noticed I made a small type. For some reason things were still funning fine, IE the tests, but compilation by atom-elixir wasn’t. We’re all good now! There are some small things I miss from vscode, but atom-elixir is great so far!

How do you fare with linter-credo? I found that my CPU was spiking often on saves because of the constant recompiles.

Hmm, I don’t get that. Wonder if a plugin of mine or yours changes that… Hmmm…

I got the compile window on the right popping up each time. It pops up on compile, then closes when it’s done. I would really have liked to have that info in a new tab instead, but I don’t think that’s supported.

I was saying I didn’t work in a linear fashion - or at least a one file at a time fashion, not the compiler.

You’ve got me wanting to try the build on save feature again, so maybe I’ll give it another stab.

I only see the errors in the file that has the errors (red squiggles on the lines and I can get details at the bottom optionally), along with a red dot at the bottom that says the project has errors somewhere (which I can click on for details). What do you mean by linear fashion? Compiling is very very linear as it is, extremely linear.

Everyone should really be using credo already, heck even many root Elixir libraries itself use credo. ^.^

In Elixir everything is a function, defs are function, macro’s are functions, defmodules are functions, everything is functions. So to quote it straight out is not ‘pretty’, though perfectly correct:

iex> quote do
...> defmodule Blah do
...> def bloop, do: 42
...> def bleep(a, b) do
...> c = a*b
...> c + a
...> end
...> end
...> end |> Macro.to_string() |> IO.puts()
defmodule(Blah) do
  def(bloop) do
    42
  end
  def(bleep(a, b)) do
    c = a * b
    c + a
  end
end
:ok

See how even def is just a function call to a function named def (macro, well, special form) that takes a first argument of, say, bloop and a second argument of, say, [do: 42]? So just printing it out does not always work. Even if you special-case things in your custom formatter like def and defp and others you will miss all the other defblah’s that libraries add, they may not even start with def. The lack of knowing the types of everything makes formatting a really really really hard problem. Formatting becomes almost trivial when you know the types of everything in the AST in comparison.

This looks like a good fit for some invariant testing. Just pick a corpus of elixir files (from hex packages for example), and do something like:

new_source = format(old_source)
old_ast = Code.string_to_quoted(old_source)
new_ast = Code.string_to_quoted(new_source)
assert = remove_line_information(old_ast) == remove_line_information(new_ast)
# assuming the remove_line_information exists

This is basically what exfmt wants to preserve, right?

I think it’s not so much parsing the file, as parsing the ast the file generates, and converting that back to elixir. Some of the limitations are due to the information they get back from the ast.

This is strange. Couldn’t they just parse the file into a quoted form and then render that (unambiguously and correctly) using the style guide? Or is there a problem with this I’m not seeing?

Links to exfmt and exfmt-atom

The alpha warning is a bit scary but I’m definitly going to check this out.

Currently exfmt does not always produce semantically identical formatted Elixir. There are checks to prevent data loss, but please ensure you have backed up your code before running exfmt during this alpha stage.