Language Server Protocol(github.com)
github.com
Language Server Protocol
https://github.com/Microsoft/language-server-protocol
30 comments
Previous discussion: https://news.ycombinator.com/item?id=11988446
I'm on the fence about this, standardization let's people pool resources to provide common functionality, but it also ossifies the interface so that doing anything not supported by the interface becomes harder than before.
The first thing that pops into my head is that for languages with interprocedural type inference, I really want my IDE to show me what types it has inferred, but this is outside the spec and not even applicable to all languages.
The first thing that pops into my head is that for languages with interprocedural type inference, I really want my IDE to show me what types it has inferred, but this is outside the spec and not even applicable to all languages.
wouldn't inferred types fit into the "Diagnostic" interface?
There are both "info" and "hint" levels which seem appropriate.
(I don't disagree with your general point, just curious about this specific example)
(I don't disagree with your general point, just curious about this specific example)
Sort of; the hover interface helps, but I would prefer it if the IDE showed it as if it was written there explicitly, not just when you hover over it.
Which requires explicit UI work, which this protocol won't support.
Which requires explicit UI work, which this protocol won't support.
With this,a new language can have an IDE integration done easily which can cover say 95% features. Some language specific feature may be obviously left out but getting a minimum viable integration to any supported IDE is a good thing.May be when this protocol evolves,it can give extension to the protocols to cover the other 5% features(or may be it is already there)
Heh. We'll see. Writing the glue code is not what makes writing language analysis hard. This is clearly a move to make the lives of IDE writers easier, rather than those who would be writing the analysis code.
But it'd make your analysis code work for multiple IDEs and editors instead of having to learn about each's peculiarities. One less thing to worry about is always good.
[deleted]
Are there any examples of extensible protocols like this in the wild? I'm asking because the only such protocol that seems to get mentioned on HN is XMPP (and always with groans).
[deleted]
We're considering moving the new Rust language service over to this protocol, or possibly, having it as a default protocol while supporting other protocols.
Since I've been learning it recently, maybe some points to help understand it:
It's just the protocol piece. Currently, VSCode will stand up the language server and communicate using the protocol over stdin/stdout. Nothing to say they couldn't support http servers in the future, but currently it seems lower level that that.
They do support hovers, which you can use for seemingly anything. We currently are using them for type information and showing API docs.
I'm hoping this takes on with other editors, as once they support it, then they'll get the stronger language support the servers provide, which can do hovers, on-the-fly error checking, code navigation, and more. It's not perfect, but as a baseline set of features, it's a pretty good starting set.
Since I've been learning it recently, maybe some points to help understand it:
It's just the protocol piece. Currently, VSCode will stand up the language server and communicate using the protocol over stdin/stdout. Nothing to say they couldn't support http servers in the future, but currently it seems lower level that that.
They do support hovers, which you can use for seemingly anything. We currently are using them for type information and showing API docs.
I'm hoping this takes on with other editors, as once they support it, then they'll get the stronger language support the servers provide, which can do hovers, on-the-fly error checking, code navigation, and more. It's not perfect, but as a baseline set of features, it's a pretty good starting set.
This is great! Abstracting away static code analysis is very helpful for people like us building browser based dev tools.
I am the developer of HiveMind (crudzilla.com), I have been dragging my feet about plunging into static code analysis so this type of solution is definitely intriguing.
I am the developer of HiveMind (crudzilla.com), I have been dragging my feet about plunging into static code analysis so this type of solution is definitely intriguing.
Well, us emacs users will finally get some decent autocomplete. So that's nice, I suppose.
This actually sounds an awful lot like what Grok was trying to do. Any relation in the development?
This actually sounds an awful lot like what Grok was trying to do. Any relation in the development?
Does anyone know what tool was used to create that diagram?
I very much doubt it was used in this case, but https://www.websequencediagrams.com/ is great if you want to do Message Sequence Charts.
The blues look like a PowerPoint theme.
You might like http://blockdiag.com/en/seqdiag/index.html
There are many ways to go about, but it could be easily achieved with any diagramming or graphics application. For example, LibreOffice Draw or Microsoft Visio.
No idea, but if you want to make similar diagrams I recommend PlantUML. Default colours suck a bit but they are easy to change.
My first guess is Visio. (Followed by Excel, PowerPoint, or Word.)
What happens when I don't have internet access? Do I install a second piece of software on by box?
The "server" in "language server" does not mean "server you access over the network" but "other process (on your machine) your editor talks to". (This is just the spec for a protocol.)
Can it be on across the internet? So, Apple can or cannot set up an internet service for Swift? If I think I have a better version can I point my editor towards that? If I program in a couple of languages, do I need to get ahold of servers to install?
> Can it be on across the internet?
In theory, yes the protocol can be used across the internet, but that would raise plenty of issues (security being a huge one). This is designed so that any program, like an IDE, can get code analysis and more without having to build special handling for each of them.
> So, Apple can or cannot set up an internet service for Swift?
Again, in theory they could. But why would they do that? Just run the server locally and get all the information there.
> If I think I have a better version can I point my editor towards that?
Yes. You simply stop the currently running language server and start the one you want to use instead.
> If I program in a couple of languages, do I need to get ahold of servers to install?
Yes. Each language would, in theory, provide its own server to do analysis. Of course, your favorite IDE would likely be more than happy to start the server for you if it's not running yet (as it's just a small process that runs in the background).
If you want to see how this works in practice just grab Visual Studio Code and start editing a Typescript file. This is already in use there.
In theory, yes the protocol can be used across the internet, but that would raise plenty of issues (security being a huge one). This is designed so that any program, like an IDE, can get code analysis and more without having to build special handling for each of them.
> So, Apple can or cannot set up an internet service for Swift?
Again, in theory they could. But why would they do that? Just run the server locally and get all the information there.
> If I think I have a better version can I point my editor towards that?
Yes. You simply stop the currently running language server and start the one you want to use instead.
> If I program in a couple of languages, do I need to get ahold of servers to install?
Yes. Each language would, in theory, provide its own server to do analysis. Of course, your favorite IDE would likely be more than happy to start the server for you if it's not running yet (as it's just a small process that runs in the background).
If you want to see how this works in practice just grab Visual Studio Code and start editing a Typescript file. This is already in use there.
> In theory, yes the protocol can be used across the internet, but that would raise plenty of issues (security being a huge one). This is designed so that any program, like an IDE, can get code analysis and more without having to build special handling for each of them.
I'm pretty sure I would be ok at part of teaching a class.
> Again, in theory they could. But why would they do that? Just run the server locally and get all the information there.
I was getting at that from the student-level. I'm pretty sure some metrics on edge problems in a remote learning class might help with the material revisions.
I'm pretty sure I would be ok at part of teaching a class.
> Again, in theory they could. But why would they do that? Just run the server locally and get all the information there.
I was getting at that from the student-level. I'm pretty sure some metrics on edge problems in a remote learning class might help with the material revisions.
To answer your points in order: No reason it couldn't talk across the Internet, I guess, if you're comfortable sending your source code to whoever is running the server and dealing with network latency on your autocomplete. Yes, you could easily point your editor to a different server, this protocol is basically just an API spec. And lastly, yes, you would (likely) need a different server for each of your languages - this project just provides a way to let an IDE implement one API client that can be used with each different language's tools.
> To answer your points in order: No reason it couldn't talk across the Internet, I guess, if you're comfortable sending your source code to whoever is running the server and dealing with network latency on your autocomplete.
I'm thinking as part of a remote learning class. I'm pretty comfortable that it wouldn't violate any student privacy rules.
I'm thinking as part of a remote learning class. I'm pretty comfortable that it wouldn't violate any student privacy rules.