Support for creating an out of process LSP?

[mrlacey]

I enjoyed the recent Hacking Visual Studio episode, which showed some of the ways that it is now easier to create an extension to support a [new] language (or file type). While these are very useful, they do not go as far as to show the ability to create a fully out-of-process LSP (Language Server Protocol implementation). Are there plans to add anything to this toolkit that could help with this?

I want to be out-of-process to avoid perf issues, and I would like to create a full, stand-alone LSP so that I can also use it with VSCode.

I would love to make such extensions but have so far failed to create any due to the complexities involved. If the toolkit could make this easier (possible--for mere mortals like me) it would be a great help.

[madskristensen]

Yes, it is something I want to look more deeply into to make super easy to do, but I have yet to had the time.

[MariaSolOs]

I've been working with LSP Visual Studio extensions during the last few months and I'm quite curious of this idea: @mrlacey Could you please elaborate on what your goals are? Would you like the LSP server to be written in C# and be a standalone component that you could later use with a LanguageClient object as defined by vscode-languageclient/node?

[mrlacey]

I've been working with LSP Visual Studio extensions during the last few months and I'm quite curious of this idea: @mrlacey Could you please elaborate on what your goals are? Would you like the LSP server to be written in C# and be a standalone component that you could later use with a LanguageClient object as defined by vscode-languageclient/node?

I have three goals.

1. I have extensions that do things with XML files. Because there are no natural extension points for extending the editor to work with these files, I use a lot of different extension points and hook things up in lots of different ways. My hope is that
2. I have extensions that treat files as text for simplicity of integration but are a bit slow, especially when working in proc. My hope/expectation is that if I could reimplement these as a LSP that the integration would be simpler, the logic centralized, and more easily testable. Plus as being out of proc it would avoid some of the issues I've had with perf (& being flagged as the cause for slow startup even when the extension isn't doing anything.)
3. I have experimental languages it would be useful to integrate by creating an LSP.

I want to create an LSP in C# to work within Visual Studio. integration with VSCode is a stretch/future goal and not an initial concern.

[MariaSolOs]

I have three goals.

1. I have extensions that do things with XML files. Because there are no natural extension points for extending the editor to work with these files, I use a lot of different extension points and hook things up in lots of different ways. My hope is that
2. I have extensions that treat files as text for simplicity of integration but are a bit slow, especially when working in proc. My hope/expectation is that if I could reimplement these as a LSP that the integration would be simpler, the logic centralized, and more easily testable. Plus as being out of proc it would avoid some of the issues I've had with perf (& being flagged as the cause for slow startup even when the extension isn't doing anything.)
3. I have experimental languages it would be useful to integrate by creating an LSP.

I want to create an LSP in C# to work within Visual Studio. integration with VSCode is a stretch/future goal and not an initial concern.

Thank you @mrlacey for explaining! So your goals all sound plausible to me, and LSP does sound like a good solution. From my experience, I would suggest the following: Start by implementing the LSP server in whatever language you desire. I would recommend a JS/TS server because vscode-languageserver makes that quite easy, but that's just me. Once you have that ready, you'll implement a client for each IDE that you want to support. A good example is Angular. The server is available as an npm package that each editor can start as an external node process. Here's the client for vscode and this is the one for Visual Studio. Despite the different clients (implemented in different languages) the server is the same.

Hopefully that helps! :) Now, I wonder which are the extensibility features that you would like the Toolkit to provide. Could you please share your ideas on this?

[mrlacey]

Now, I wonder which are the extensibility features that you would like the Toolkit to provide. Could you please share your ideas on this?

I'd like a template to help get started ;)

[CalvinAllen]

@mrlacey This is extremely similar to what we're doing on CodeStream - i.e., a node backend that is spawned from a LanguageClient in Visual Studio. The same node backend is used in our VSCode and IntelliJ extensions. Its all OSS, check it out - https://github.com/TeamCodeStream/codestream. The LSP is in shared/agent, and then "shared" amongst all the individual extensions.

[MariaSolOs]

@CalvinAllen That's a really cool! Definitely a very useful reference for people getting started with LSP.

@mrlacey I'm unsure of how useful a template would be, given that the implementation for an LSP service depends on a bunch of things: Is the server in-proc or running in another process? What content types to use? Are there any middle layers or custom non-LSP messages that would need the client to implement ILanguageClientCustomMessage2? No matter what users would need to add and/or remove a lot of stuff from the template to make it fit to their needs...

That being said I'm also aware that the documentation for LSP in Visual Studio isn't the best, and it's very hard to find a project to use for inspiration or as a starting point.

[mrlacey]

@MariaSolOs Ok, maybe a template wouldn't be the best right now. I'd settle then for an example LSP written in C# and with out-of-proc integration with VS.