Move the generic LS implementation to a separate repo?

[robertoaloi]

Hi Pierrick,

we recently created an organization named erlang-ls, whose purpose is to have a common space for members of the Erlang community who want to leverage the Language Server Protocol to improve support for the Erlang programming language in the most common editors and IDEs (e.g. Emacs, Vim, Eclipse, VS, etc).

Since it looks like you already have an existing server implementation, I wonder if you would be interested in moving the non-VS specific parts to a separate, common, repo (ideally under the same organization, of which you could become a moderator and collaborator), so that other community members could use it in combination with other clients.

The org is at very early stage (the idea came out during the Code Beam Stockholm) and preliminary discussions are happening at erlang-ls/erlang_ls#1 and in the #language-server channel in the Erlanger Slack.

Regarding licenses, the idea is to release all the components under the erlang-ls org as Apache 2, to be aligned with the license used by Erlang itself.

Let us know if you are interested.

[pgourlain]

Hi @robertoaloi ,

Good idea !

At the beginning, I made this extension for Visual Studio Code in order to compile/debug my personal Erlang projects.

Do you know this project 'https://github.com/erlang/sourcer' ?
it seems to be non-specific.

@wojteksurowka did a great job to port LS fully in Erlang.

So today, because your are in early stage, a copy of Erlang code can be integrate in your repo.
Then before I use the output of erlang-ls, we should discus about your vision for releases workflow, and so on.

I work every days on Microsoft .Net platform, and one feature is important for me, is the support of many runtime version by the IDE (Visual Studio). So, today the Erlang code is compiled on target machine using the current version. And OTP 18, 19, 20... can be targeted. May be is not the best way, but you can see what I mean.

[wojteksurowka]

We are still at the stage of development when new features are added often, significant refactorings are done often, and generally the Erlang extension - including the language server - is in the state of continuous improvement.
I think this very fast pace is very beneficial to the project, and any impediments should be avoided. Build complications are one thing, but support for several platforms instead of just one - even when they conform to the same protocol - would be obviously more costly.
I started contributing to the project because I want Erlang experience in Visual Studio Code to be ideal, and my sole focus is on VSC. Potentially it could be beneficial to other IDEs but it is still too early now. I agree that using sourcer sounds like the right choice now, especially that its creator is involved in erlang-ls.

[robertoaloi]

Hi both, fair enough.

Support for multiple OTP version is something I'm highly interested into as well, since I usually work with different versions at the same time. Something that EDTS only solves partially.