Language-server-protocol: Language Server persistency

Created on 9 Jan 2021  路  5Comments  路  Source: microsoft/language-server-protocol

Is your feature request related to a problem? Please describe.
Hi, my way of working is editing files with vim all over the place (I like to have my code split into files), quickly going in and out of files. This way, I'm starting and quitting vim quite often. Some language servers take quite some time to start (for example LanguageServer.jl) and that means that if I want to see their output, I have to wait quite a lot...

Describe the solution you'd like
I would like for language servers and to be able to persist even after closing the editor. I imagine it as there being some timeout, for example 5 minutes, so that when I close my editor and reopen it inside 5 minutes, the language server would still be running and wouldn't need to start again.

Describe alternatives you've considered
Changing my working habits by opening files directly from vim. Not nearly as quick and simple (for example I can't change directories...)

I've been redirected here from neoclide/coc.nvim#2797

discussion

Most helpful comment

I guess one way to solve this problem is to have a long-running daemon process that manages the different opened language server processes. When an LSP editor opens it would connect to the daemon process to exchange messages instead of booting up language server processes itself. 馃

All 5 comments

@marekdedic What would you like the protocol to do? Are you suggesting that LSP editor clients should offer a way to leave language server processes around for N seconds instead of terminating them when the client closes?

I think this should not be specified in the protocol but up to the client implementation.

Hi,
honestly, I don't understand the LSP spec and cannot comment on whether this should be part of the spec or implementation.

Yes, I thought of the editor and the server negotiating the language server not being terminated for some time after the editor is closed. So if the editor is immediately reopened, it could reconnect to the server that is still running. I imagine the spec could help by setting how the editors should reconnect to a running language server instance and "negotiate" the persistency. Otherwise, I think it would be a bit of a "chicken and egg" problem of neither servers nor clients implementing this first :)

Thanks!

I guess one way to solve this problem is to have a long-running daemon process that manages the different opened language server processes. When an LSP editor opens it would connect to the daemon process to exchange messages instead of booting up language server processes itself. 馃

I will keep that as a discussion item open. But it can only be an implementation recommendation since something like this currently lies outside of the specification.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

gorkem picture gorkem  路  6Comments

Franciman picture Franciman  路  3Comments

pajatopmr picture pajatopmr  路  3Comments

ooxi picture ooxi  路  3Comments

Wosi picture Wosi  路  6Comments