Documentation

[david-driscoll]

Need to write up some high-level and lower-level documentation on how the server is supposed to work. What the overall goals and so on.

[tintoy]

I might have a go at this later this week if nobody else is taking it :)

[ManishAgrawal1410]

Have someone prepared a document around this? If yes, please share.

[svermeulen]

+1 to some documentation. My impression is that the best documentation is the source code for the servers that are currently using this (eg. omnisharp-rosylyn) which take a lot of time to read through and understand

[svermeulen]

Can someone confirm that this library can be used to create LSP serverss for languages that are not based on .NET?

[david-driscoll]

@svermeulen yes! This library is specifically for creating language servers using .NET.

[mikkleini]

I've used it for a server implementation for a while now and I would say it's easy to grasp the idea when you look at the MS LSP specification in parallel. Sample project shows the basics and it's no problem to add more handlers. Things get complicated when you have to build a well functioning server. I put quite a lot of effort into these topics:

• Multi-threading. There can be parallel requests coming in. However @david-driscoll explained in some other topic, that "write" requests are queued and not processed in parallel. That makes implementation simpler. Nevertheless, the "read" requests like links and references requests should be handled in parallel to the changes for performance reasons. Hereby I suggest to use immutable objects everywhere (C# 9.0 "record" is really handy). Even though it looks like a waste to re-create objects on each analysis step, it's safer and robust. Based on David's suggestion I also recommend using DynamicData library for collections.
• Not processing every single keypress. There could be massive projects and last thing you want is CPU throttling at every keypress. After observing other implementations I found the best way is to have a 500 ms delay between last keypress and analysis. However that brings a special problem if you use diagnostics and highlight an issue in the code. If a user inserts a line or does any other shift before a highlighted issue, the higlighted range stays at the same absolute position for 500 ms because client (at least VS code) does not move it along with the subject. Basically diagnostics need to be re-positioned and published at every keypress. There is some thinking and math involved.
• Mixing the opened and not opened document. If you do analysis of a whole project, not just single document, then it's not enough to deal with document open/change/close handlers, because all those other not-opened documents can be created/deleted/renamed/moved by the client editor and by any other external editor. Need to watch for workspace folder and file system changes in parallel and adapt when file is opened/closed by the client.

It wasn't the actual documentation, but I hope it helps when somebody wants to start with it.

[david-driscoll]

@mikkleini I appreciate the additional feedback!

I'm going to be looking at getting some better docs together, more focused on ideas like these. Implementing the spec is straight forward (as you noted) but some of the ideas and concepts and how things are put together.

[Soya-Onishi]

Is there a plan to publish document comments in package? I want to read documentation in editor for easy reference.