Elixir IDE discussion

Have you ever run into this when using atom-elixir? https://cl.ly/llxj

Nope but that’s not an atom error, that’s an error with the elixir build. It happens in other cases as well. A quick google search:

Among others.

The gist of it though seems to imply that either your current compile is corrupt, or you have beam files currently in your project that were compiled with a different OTP version (did you just upgrade OTP and did not delete your _build directories in all your projects?). But it is an error with mix building things, not atom, atom is only reporting what mix reports it (the elixir integration runs an elixir daemon to query the elixir system directly).

I had those some time ago, but with the latest version at least the wrong coloring is gone. And as @law wrote, compiling often helps much with autocompletion i think.

@OvermindDL1 you can’t disable cmd+click or redefine it to something sane in atom https://github.com/atom/atom/issues/7595 the issue is still not fixed for past two years :joy:

More, I don’t think you can’t “keybind” any mouse event :confused:

Nah… I’ll stay witch vs-code it’s faster, easier to configure, there’s plugin to give you IDEA-keybindings and most of the time everything just works :wink:

Really? Because my Ctrl+Click does not do another cursor, it instead Go To Definition’s. ^.^

Maybe it is just a hack/override hyperclick did, but it works. ^.^

Except it misses a lot of the functionality I really rely on, no plugins that I could find for a lot of features, which is why I’ve not moved to it yet. When it does then I probably will move. :slight_smile:

I think it depends on language and package installed. For Ocaml I am unable to set it :confused: And for Elixir… I don’t really remember now :neutral_face: But yes, actually you can hack to make clicks keybindable, but that involves doing some Is magic on atom’s internals :stuck_out_tongue: With “normal” keybindings you can’t mess with mouse in any way.

I actually don’t need much functionality other than linting, colouring, going to definition, and type in popup (for languages like for example Rust), and builtin diff view in vs-code is very good anyway. So I guess to each its own. And I’m really glad we have all those editors to choose from, so anyone can find what suits him/her best :slight_smile:

1 Like

It’s just my coding style - I may have incomplete or partial implementations as I switch between files and built out architecture. I also tend to auto-save when I switch files. Combine the two, and compile errors popup a lot, which I found disruptive. If I worked in a more linear fashion it’d be different.

Ok. I’ll give a try to this plugin once again. What version of IntelliJ are you using now?

Latest one, i’m not on my work computer now, so can’t say for sure but i believe it’s v5.1.0

Have you folks tried VSCode? I’ve had always the best experience with it and Elixir. :slight_smile:

Which plugins are you using in vscode?

vscode-elixir, vscode-credo and vscode-exfmt. Although for the last two to work, you need credo and exfmt installed as dependencies in your project, which is not a problem at all. :slight_smile:

1 Like

And for the vscode-elixir plugin to do autocompletion, you need to have your dependencies compiled, so do a compilation before trying to use autocomplete. :slight_smile:

exfmt is already a thing? Whoa!

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.

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?

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.

1 Like

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?

2 Likes

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.

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. :slight_smile:

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

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