ElixirLS - the Elixir Language Server

JakeBecker · April 29, 2018, 9:17pm

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:

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

gregvaughn · April 29, 2018, 10:54pm

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

jswny · April 30, 2018, 12:05am

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

JakeBecker · April 30, 2018, 2:34am

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.

jswny · April 30, 2018, 2:08pm

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.

JakeBecker · August 5, 2018, 5:23pm

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:

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

OvermindDL1 · August 6, 2018, 6:19pm

Woooo!

ChaseGilliam · August 10, 2018, 2:14pm

That is phenomenal!

myronmarston · August 15, 2018, 6:16am

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…

LostKobrakai · August 15, 2018, 9:39am

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.

myronmarston · August 15, 2018, 2:20pm

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

mroach · November 2, 2018, 2:29pm

I got his working with Sublime Text 3!

Install the LSP package
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
At the command palette, find Preferences: LSP Settings
Make your clients section look like this:

LSP.sublime_settings

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

belaustegui · January 12, 2019, 3:32pm

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 %>

belaustegui · February 8, 2019, 9:42am

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.

NobbZ · February 8, 2019, 9:55am

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.

jayjun · February 8, 2019, 10:23am

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

NobbZ · February 8, 2019, 10:24am

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

belaustegui · February 8, 2019, 10:44am

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.

tme_317 · February 8, 2019, 12:25pm

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.

NobbZ · February 8, 2019, 12:26pm

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.