Remote language server proposal

[Yanpas]

Currently LSP servers and clients implementations use some local IPC to communicate. But there is not uncommon workflow where you develop a software that is unbuildable on the developer machine and is built on some virtual machine. E.g. developing Linux daemon on Windows. Sometimes machine where you write a code is not very powerful or energy-efficient (some ultrabook).

I propose extending language server protocol over a network. TCP transport should be transparent replacement for pipes, stdin+stdout or unix sockets since it's stream oriented too.

[keegancsmith]

There is nothing in the spec which dictates transport. Quite a few existing language servers already support TCP as the transport. In fact at Sourcegraph we run LSP servers as a remote service using plain old TCP.

What is missing from the spec is handling remote files (remote in the sense of files existing only on the server or client). We use some custom LSP methods so servers can fetch files from clients for example, but this is not in the spec.

[Yanpas]

Yes, keeping the source code base synchronous across client and server is what currently limits remote client/servers. Since virtual file systems are not portable I think VCS (git e.g.) is a good candidate for file-synchroniztaion. (client and server ensure that they both use same branch and commit, all file-edits are transferred as a patch)

[keegancsmith]

Since virtual file systems are not portable

What do you mean? The server doesn't need an OS level VFS for this to work, the application can just ask for files. Most LS already have this sort of logic baked in due to supporting didOpen/etc.

[Yanpas]

Some language servers (cquery) require access to all files of the project which is large amount of data. Passing it each time server launches is an overhead

[Piping]

Develop your code in the server using a TUI editor with LSP support.

[vscodebot]

We closed this issue because we don't plan to address it in the foreseeable future. You can find more detailed information about our decision-making process here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!