-
Our setup uses one shared workspace per "project" (actually: per customer). If we switch from bitlang.cobol to superbol now, every developer would likely run a separate instance of the lsp creating a cache directory under the users's vscode storage. So: would it be possible to use one single cache per workspace? Would it be possible/useful to let all vscode instances query the same LSP? ... and as there was not much "discussion" here before - friendly ping @nberth to possibly ping the right people :-) |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
The LSP protocol itself is not designed to support multiple clients per server, and there does not seem to be any plan to extend it to add such a feature (cf microsoft/language-server-protocol#1160 — IMHO thankfully, given the technical intricacies that such an extension to the protocol would bring). So the only remaining option is to store the cache in a shared location (like in the project itself) and access it via multiple LSP servers. At the moment that's not supported (the cache itself is a single file that's juste blindly read on LSP server startup and written on shutdown), but I think moving towards a different storage scheme for the cache would not be too complicated. |
Beta Was this translation helpful? Give feedback.
The LSP protocol itself is not designed to support multiple clients per server, and there does not seem to be any plan to extend it to add such a feature (cf microsoft/language-server-protocol#1160 — IMHO thankfully, given the technical intricacies that such an extension to the protocol would bring).
So the only remaining option is to store the cache in a shared location (like in the project itself) and access it via multiple LSP servers. At the moment that's not supported (the cache itself is a single file that's juste blindly read on LSP server startup and written on shutdown), but I think moving towards a different storage scheme for the cache would not be too complicated.