Introducing ElixirLS, the Elixir Language Server

Hi! Glad you like ElixirLS!

Some people seem to have gotten ElixirLS working in neovim, though the plugin system for neovim seems complicated and I haven’t gotten it working myself. Someone using it in neovim just posted their vimrc in an issue (now resolved), which is here in case it’s helpful: https://github.com/JakeBecker/elixir-ls/issues/76

I’m not up to date on the progress of the LanguageClient-neovim plugin, but based on your description and issues people have filed on ElixirLS, there’s a couple areas where its support for the protocol is incomplete:

  1. The client should send the configuration (which in VS Code is specified in settings.json) via the workspace/didChangeConfiguration request, but according to this issue the Neovim client doesn’t do that yet, so there’s no way to specify these settings. (EDIT: Actually, it looks like it does support this, though you might need to turn on a setting for it? Looks like it was added here.)
  2. The autocomplete snippet syntax is specified here as part of the Language Server Protocol. When the server first starts up, the client sends an initialize request to the server which includes a parameter for clientCapabilities, and if the client doesn’t support snippets, it should set snippetSupport to false. I assume Neovim omits this, so ElixirLS defaults to including the snippets.

Hope that helps!

PS. The Vim emulation plugin for VS Code is pretty good, and I haven’t missed Vim since I switched to using VS Code. By complete coincidence, the Vim plugin for VS Code was written by a former roommate of mine.

2 Likes

Thanks for the speedy weekend reply @JakeBecker !

Sometimes the internet is a small place. The author of your issue 76 and I have been conversing this weekend in the Elixir Slack #vim channel :slight_smile: Some of the complexities are compounded in the error reports in that there are 2 different vim plugins acting as a client of Language Servers. I’ve tried them both, but gotten farther with LanguageClient-neovim.

Thanks for the pointers. It appears I have 2 main things to learn about LanguageServers: clientCapabilities and workspace/didChangeConfiguration. I’m getting a better picture for which pieces of the puzzle are responsible for what.

PS. I appreciate what you’re saying, but my vim habits include features that are more than skin deep, and I’m going to keep down this path for now.

Personally, I’ve found that the Vim emulation for VSCode is not very good, even basic commands such as . don’t work right. Either way, I prefer the actual Vim because of the customization, although VSCode is great in its own right.

I authored the issue that you specified, and I’ve been talking to @gregvaughn on Slack about it as well. Since then, I’ve gotten the diagnostics and completion with Deoplete working fantastically! However, I did notice the problem with LanguageClient-NeoVim not sending workspace/didChangeConfiguration requests. I’m going to try and open an issue about that as the client should conform to the spec, and without it I have to wait 5 seconds for ElixirLS to use default settings since the client isn’t sending the right requests.

Again, thanks for your hard work and for the great project @JakeBecker. ElixirLS has really leveled up my editing experience :slight_smile:

2 Likes

Glad to hear it’s working well. I’m not familiar with how Neovim plugins are built – is it something you could readily package up and redistribute? It sounds like that would be helpful to people, but I get the feeling it might be a bit tricky.

I’m certainly not an expert but from what I know NeoVim and Vim plugins are actually quite simple. You simply clone the repo somewhere and then add that folder into your Vim runtime path. NeoVim has some additional APIs that plugins can take advantage of but overall the process for distributing plugins is the same. Most plugin managers simply clone and pull repos with a bit of niceties on top.

I just released an update that improves compatibility with Elixir 1.7, fixes some bugs, and adds two new features:

  • Auto completion for struct fields inside of %SomeStruct{}. (Thanks to @msaraiva and Elixir Sense)
  • Automatic suggestion of @spec annotations for public functions using Dialyzer’s inferred success typings:
    53%20AM

Translating Dialyzer’s contracts to Elixir syntax was made much easier by the excellent erl2ex library by @dazuma. Happy coding!

29 Likes

Woooo!

3 Likes

That is phenomenal!

2 Likes

Automatic suggestion of @spec annotations for public functions using Dialyzer’s inferred success typings:

How do you get it to suggest a @spec? I couldn’t figure it out…

Afaik dialyzer is not using your manual typespecs to determine specs, but it does infer types on it’s own and it does so for any function and not just the ones you supplied typespecs for. It uses manual typespecs just to compare against it’s inferred results and find mismatches. ElixirLS is using what dialyzer thinks the typespecs are.

Yes, but how do I get VS Code to show the suggestion?

1 Like

I got his working with Sublime Text 3!

  1. Install the LSP package
  2. Create an executable bash script to start elixir-ls. Mine just does a cd to the dir where I cloned it and then mix run --no-halt
  3. At the command palette, find Preferences: LSP Settings
  4. Make your clients section look like this:

LSP.sublime_settings

{
  "clients":
  {
    "elixir-ls":
    {
      "command": ["~/bin/elixir-ls"],
      "enabled": true,
      "languageId": "elixir",
      "scopes": ["source.elixir"]
    }
  }
}
3 Likes

Hi! Just chiming in to say that I’ve been using the Language Server extension in VSCode almost since it was released and it has been absolutely great.

Today I’ve contributed a pull request that improves the declarative configuration both for Elixir source code and EEx templates:

  • Avoids autoclosing quotes when writing comments or inside strings.
  • Add multiple useful snippets for defmodule, def, @doc and much more.
  • Allow commenting lines with <%# ... %> tags in EEx templates.
  • Automatically close <% tags in EEx templates with the corresponding %>
14 Likes

First of all I want o say that as many others in the Elixir community I am forever grateful to @JakeBecker or writing such an awesome piece of software. Almost since it was first released, the Elixir Language Server has been my companion for writing Elixir code every day.

Sadly, the project seems to be in an hiatus for the last months, with lots of PRs containing fixes and improvements piling up. I am not saying this as a rant (God forbid me, I know how card free software maintainership can be), but as a constructive criticism.

I have seen that some folks have forked the Elixir Language Server project into its own organization. I’ve took a look at the repo and it seems to have include lots of the improvements that are enqueued for the original Elixir Language Server.

This seems like a good step to me. Having multiple people maintaining a project ensures that community contributions can be reviewed and merged faster and improvements are made more frequently.

So, at this point I am wondering about which Elixir Language Server should be used. Also, the fork seems legit, but knowing the opinion of @JakeBecker about it would be really interesting for the community.

PS: at this point the only extension available in VSCode uses the original Elixir Language Server, so as far as I know there is no way to use the forked project with VSCode. I don’t know if it would be useful to also fork the VSCode extension (I see that there is an Emacs package hosted in the organization). I think that the process could be more complicated, since the extension should be published with a different name.

So, this can be summarized as “a user that loves the Elixir Language Server” is concerned about its future".

I am also taking the opportunity to mention @asummers, @axelson, @NobbZ and @Trevoke to know their opinnions, since they are the owners of the fork.

PS: thank you all for you awesome work which is useful for so many developers.

16 Likes

We agreed on releasing a new VScode plugin, as soon as it meets some standards. As it may take quite a while until our issues have been solved (no one of us is a JS/TS guy) we have not yet discussed the name or namespace to use for a release.

3 Likes

Where are such discussions taking place? I’ll gladly help, sign me up.

2 Likes

Most communication happens in the elixir slack and we currently use the #emacs and #alchemist-dev channels for discussion.

1 Like

I could also help with the VSCode extension. Most of it is simply declarative features such as snippets, grammars, etc. The programmatic part is very very small since it simply calls the Language Server implementation.

2 Likes

Does it make sense to fork the existing VScode plugin inside the new GH org at this point? The only change right away would be to use the forked elixir-ls (which uses the forked ElixirSense) instead?

Then the community can document and iterate on the issues. We wouldn’t even need to publish it on MSFT yet with a new name until it meets some standards as it’s easy for the early users to manually install compiled .vsix files.

2 Likes

I have already a fork on my account and will move it to the org during the upcomming weekend, I’ll need to fix some minor things at least first.

10 Likes