I got his working with Sublime Text 3!
cd to the dir where I cloned it and then mix run --no-haltclients section look like this:LSP.sublime_settings
{
"clients":
{
"elixir-ls":
{
"command": ["~/bin/elixir-ls"],
"enabled": true,
"languageId": "elixir",
"scopes": ["source.elixir"]
}
}
}
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:
defmodule, def, @doc and much more.<%# ... %> tags in EEx templates.<% tags in EEx templates with the corresponding %>
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.
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.
Most communication happens in the elixir slack and we currently use the #emacs and #alchemist-dev channels for discussion.
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.
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.
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.
Am I incorrect in thinking once the org is setup the vscode plugin (and its PRs) could be forked / renamed / released for those waiting on the PRs? Sounds like the language server itself will require a tad more work.