Language Server Protocol • Hacker News Board

Re: Language Server Protocol

#11

Post by avita1 » Mon, Oct 03, 2016, 3:00 PM UTC

hitr wrote: post #4

Eridrus wrote: post #3

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 ev…

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)

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).

Re: Language Server Protocol

#12

Post by qwertyuiop924 » Mon, Oct 03, 2016, 3:08 PM UTC

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?

Re: Language Server Protocol

#13

Post by falcolas » Mon, Oct 03, 2016, 3:19 PM UTC

I only glanced through the document, but I didn't see anything which could verify that the "Tool" and the "Language Server" are both referring to the same content. Is there a mechanism for handling this kind of synchronization drift?

Re: Language Server Protocol

#14

Post by Eridrus » Mon, Oct 03, 2016, 3:19 PM UTC

hitr wrote: post #4

Eridrus wrote: post #3

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 ev…

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.

Re: Language Server Protocol

#15

Post by protomyth » Mon, Oct 03, 2016, 3:26 PM UTC

What happens when I don't have internet access? Do I install a second piece of software on by box?

Re: Language Server Protocol

#16

Post by killercup » Mon, Oct 03, 2016, 3:47 PM UTC

protomyth wrote: post #15

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.)

Re: Language Server Protocol

#17

Post by protomyth » Mon, Oct 03, 2016, 4:00 PM UTC

killercup wrote: post #16

protomyth wrote: post #15

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?

Re: Language Server Protocol

#18

Post by lann » Mon, Oct 03, 2016, 4:29 PM UTC

qwertyuiop924 wrote: post #12

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?

See Kythe (Google OSS): http://kythe.io/

Re: Language Server Protocol

#19

Post by icholy » Mon, Oct 03, 2016, 4:31 PM UTC

falcolas wrote: post #13

I only glanced through the document, but I didn't see anything which could verify that the "Tool" and the "Language Server" are both referring to the same content. Is there a mechanism for handling this kind of synchronization drift?

See TextDocumentSyncKind and TextDocumentItem.

Re: Language Server Protocol

#20

Post by Arcsech » Mon, Oct 03, 2016, 4:44 PM UTC

protomyth wrote: post #17

killercup wrote: post #16

Earlier quoted context omitted.

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?

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.