8 ms·

A source of knowledge for Language Server Protocol implementations

129 points by rayascott 9y ago

frou_dh 9y ago
It's surprising that there's no Go language server with code-completion support. Isn't most of the machinery to extract that information from source text present in the standard library? https://golang.org/pkg/go/ https://golang.org/pkg/go/
- deleted 9y ago
  [deleted]
- dualogy 9y ago
  There's a couple of popular CLI tools for code-completion and other "IntelliSense"-ish functionality that are meant to be editor-agnostic --- ie. "focus on just your editor-specific plugin plumbing and use these proven CLI tools for the underlying language intelligence". (I made a list of useful, stably working ones about half a year ago when hacking on a custom VScode plugin, many but not all of them linters, haven't looked into latest developments: https://github.com/metaleap/go-util/blob/master/dev/go/devgo.go#L19 https://github.com/metaleap/go-util/blob/master/dev/go/devgo... ) Just that maybe none have fully implemented LSP. I guess even a from-scratch Golang LSP implementation might do well to just utilize these tools for underlying lang intel --- rather than these tools themselves bloating up by implementing some maybe-just-transient-maybe-the-future current-day MS-backed protocol.
  - frou_dh 9y ago
    I like the plethora of linters. It's generally straightforward to wire up custom linters and parse file:line:column from their stdout, since that's an age-old paradigm (overlap from compiler errors). Code completion has a much higher bar for acceptable UI, though. I trust a Language Server Client with tons of users/contributors to deliver non-idiosyncratic UI sooner than MVP UI integrations of specific tools. A good example of this is "Tern" for JavaScript. It (the backend indexing/completion engine) is absolutely killer, but the tightly coupled editor plugin/package just for Tern is decidedly "meh". I suspect because hardly anyone is developing, or indeed using, that specific integration. --- Regardless of the overall merit of the Language Server initiative, the "matrix vs column" problem they articulate is bang on the money in terms of delivering quality (non-idiosyncratic) UI.
    - dualogy 9y ago
      > Code completion has a much higher bar for acceptable UI, though. I trust a Language Server Client with tons of users/contributors to deliver non-idiosyncratic UI sooner than MVP UI integrations of specific tools Apt for the client-side. But as for "there's no Go language server"--- It's still more sensible for a say Golang LSP implementation (the server side) to rely on the existing `gocode` tool and related tooling as underlying to deliver auto-completion, than reinvent the wheel here. These have already been battle-tested and encountered+fixed god-knows-how-many quirks that can occur when attempting to furnish a most-useful-for-current-cursor-context code completion. Which kinda was my point. Anyone is free to wire up a say Golang LSP implementation without needing to redo all that the exising tooling already does well. If nobody felt like doing such an LSP server to-date, it's probably mostly because it's a young protocol still looking to find adoption beyond VS --- the ole' chicken'n'egg =)
      - frou_dh 9y ago
        Hey thanks. You prompted me to look into `gocode` again and I've got it working a lot better than when I last gave it a shot.
tiben_ 9y ago
That's pretty interesting. I use Eclim (vim + eclipse headerless) everyday for my Java projects. Has someone already tried the Java lang servers, especially with Vim? How does it compares with Eclim ?
- nerdponx 9y ago
  This is my concern with the LSP. It's a wonderful idea, but its widespread adoption also implies abandoning many well-liked language-specific tools like Eclim.
  - zaarn 9y ago
    I think it can work hand-in-hand; general support via LSP and tight coupling with additional augmentation.
    - tiben_ 9y ago
      I don't know how feasible it is but i agree, it would be a pity to have to throw away Eclim because of LSP.
  - dtech 9y ago
    It's not really meant to replace well-performing existing editor-language integrations with a large user base and active development. What it's awesome for is new editors and languages. If editors implement this interface they immediately have decent support for a decent number of languages, and if a language implements this it immediately has basic support in all editors supporting LSP. Microsoft originally developed this for their Visual Studio Code and Typescript integration, both of which faced the typical challenges new editors and languages have with support.
hammerandtongs 9y ago
Notably and regrettably absent is Kotlin - https://discuss.kotlinlang.org/t/any-plan-for-supporting-language-server-protocol/2471 https://discuss.kotlinlang.org/t/any-plan-for-supporting-lan... Java seems usefully far along however...
- teddyuk 9y ago
  i wonder if this is a symptom of having a tools vendor (who only makes money via tools) create a language?
  - deleted 9y ago
    [deleted]
  - chubot 9y ago
    I suspect that they have a lot of bells in whistles in IntelliJ that are not possible over the language server protocol. But yes it from a business perspective it doesn't make much sense to devote a lot of manpower to making competitors more capable.
    - cwyers 9y ago
      Microsoft seems to currently be investing a lot of effort in making developing .NET server apps on a competitor's platform more capable, so I think it's not as cut and dried as that. If you develop a "good enough" LSP server for Kotlin, and have the "best of breed" tools in IntelliJ, then you potentially increase the pool of Kotlin developers, which creates network effects making Kotlin development more appealing, and then you see more IntelliJ use. There can be benefits to making your platform play well with your competitors, if you can still monetize the platform.
      - deleted 9y ago
        [deleted]
  - igneo676 9y ago
    It looks like they maintain plugins for other IDEs - notably Eclipse https://github.com/JetBrains/kotlin-eclipse https://github.com/JetBrains/kotlin-eclipse The root cause seems to be the community. Few Kotlin developers use anything but an IDE so there's little motivation to bring tooling to other editors like LSP would
xg15 9y ago
I still don't get it. We could create a parser framework that allowed a client to get some sort of generic AST and reference graph - which would enable all the use-cases of language servers but would also allow more use-cases in the future (e.g. IntelliJ-style inspections or language-aware diffs). Instead, the standard requires running half a dozen processes with an API that doesn't provide anything except the exact data required for a number of handpicked use-cases. Considering that even modern IDEs (again, see IntelliJ for examples) can do more, I don't see how this is a good way forward.
- zaphar 9y ago
  A generic AST and reference graph that shipped a common denominator of languages is not as easy to do as a set of common operations and queries I think you may be underestimating the feasibility of what you propose.
  - teabee89 9y ago
    You mean overestimating the feasibility.
  - jblow 9y ago
    You don’t need to do a generic AST. Have it be a protocol ... that runs in-process via an API. Because you know what, that’s what an API is ... a protocol for communicating with someone else’s code. But you don’t have to run extra processes or suffer context switches, and you don’t have to be in the business of debugging distributed systems in order to accomplish any tiny thing. Amazing!!! This whole LSP thing is a mindbogglingly bad idea, brought to you by the same kinds of thought processes that created the disaster that is today’s WWW.
    - klmr 9y ago
      Right, this seems obvious. Any idea why they opted not to go that way? I guess the reason is that the original use-case was VS Code & TypeScript (?) and developing a lowest common denominator API for all clients would mean C, so they would have had to program to a C API even though both the client (VS Code?) and the server (Node?) are running JavaScript. But then maybe the answer should be to provide better C invoke wrappers for high-level languages, not to use HTTP instead of C.
zabil 9y ago
We are in the process of adding full support for language server protocol into our testing tool https://github.com/getgauge/gauge-vscode https://github.com/getgauge/gauge-vscode and it's been a great experience. In the past, we implemented these features for every IDE plugin (IntelliJ, Eclipse, Visual Studio) and it's tough to build, test or debug. With language server, we build all these features in our tools language i.e. Golang, and it works for any IDE that supports the protocol.

129 points by rayascott 9y ago

It's surprising that there's no Go language server with code-completion support. Isn't most of the machinery to extract that information from source text present in the standard library? https://golang.org/pkg/go/ https://golang.org/pkg/go/

deleted 9y ago
[deleted]
dualogy 9y ago
There's a couple of popular CLI tools for code-completion and other "IntelliSense"-ish functionality that are meant to be editor-agnostic --- ie. "focus on just your editor-specific plugin plumbing and use these proven CLI tools for the underlying language intelligence". (I made a list of useful, stably working ones about half a year ago when hacking on a custom VScode plugin, many but not all of them linters, haven't looked into latest developments: https://github.com/metaleap/go-util/blob/master/dev/go/devgo.go#L19 https://github.com/metaleap/go-util/blob/master/dev/go/devgo... ) Just that maybe none have fully implemented LSP. I guess even a from-scratch Golang LSP implementation might do well to just utilize these tools for underlying lang intel --- rather than these tools themselves bloating up by implementing some maybe-just-transient-maybe-the-future current-day MS-backed protocol.
- frou_dh 9y ago
  I like the plethora of linters. It's generally straightforward to wire up custom linters and parse file:line:column from their stdout, since that's an age-old paradigm (overlap from compiler errors). Code completion has a much higher bar for acceptable UI, though. I trust a Language Server Client with tons of users/contributors to deliver non-idiosyncratic UI sooner than MVP UI integrations of specific tools. A good example of this is "Tern" for JavaScript. It (the backend indexing/completion engine) is absolutely killer, but the tightly coupled editor plugin/package just for Tern is decidedly "meh". I suspect because hardly anyone is developing, or indeed using, that specific integration. --- Regardless of the overall merit of the Language Server initiative, the "matrix vs column" problem they articulate is bang on the money in terms of delivering quality (non-idiosyncratic) UI.
  - dualogy 9y ago
    > Code completion has a much higher bar for acceptable UI, though. I trust a Language Server Client with tons of users/contributors to deliver non-idiosyncratic UI sooner than MVP UI integrations of specific tools Apt for the client-side. But as for "there's no Go language server"--- It's still more sensible for a say Golang LSP implementation (the server side) to rely on the existing `gocode` tool and related tooling as underlying to deliver auto-completion, than reinvent the wheel here. These have already been battle-tested and encountered+fixed god-knows-how-many quirks that can occur when attempting to furnish a most-useful-for-current-cursor-context code completion. Which kinda was my point. Anyone is free to wire up a say Golang LSP implementation without needing to redo all that the exising tooling already does well. If nobody felt like doing such an LSP server to-date, it's probably mostly because it's a young protocol still looking to find adoption beyond VS --- the ole' chicken'n'egg =)
    - frou_dh 9y ago
      Hey thanks. You prompted me to look into `gocode` again and I've got it working a lot better than when I last gave it a shot.

tiben_ 9y ago

That's pretty interesting. I use Eclim (vim + eclipse headerless) everyday for my Java projects. Has someone already tried the Java lang servers, especially with Vim? How does it compares with Eclim ?

nerdponx 9y ago
This is my concern with the LSP. It's a wonderful idea, but its widespread adoption also implies abandoning many well-liked language-specific tools like Eclim.
- zaarn 9y ago
  I think it can work hand-in-hand; general support via LSP and tight coupling with additional augmentation.
  - tiben_ 9y ago
    I don't know how feasible it is but i agree, it would be a pity to have to throw away Eclim because of LSP.
- dtech 9y ago
  It's not really meant to replace well-performing existing editor-language integrations with a large user base and active development. What it's awesome for is new editors and languages. If editors implement this interface they immediately have decent support for a decent number of languages, and if a language implements this it immediately has basic support in all editors supporting LSP. Microsoft originally developed this for their Visual Studio Code and Typescript integration, both of which faced the typical challenges new editors and languages have with support.

hammerandtongs 9y ago

Notably and regrettably absent is Kotlin - https://discuss.kotlinlang.org/t/any-plan-for-supporting-language-server-protocol/2471 https://discuss.kotlinlang.org/t/any-plan-for-supporting-lan... Java seems usefully far along however...

teddyuk 9y ago
i wonder if this is a symptom of having a tools vendor (who only makes money via tools) create a language?
- deleted 9y ago
  [deleted]
- chubot 9y ago
  I suspect that they have a lot of bells in whistles in IntelliJ that are not possible over the language server protocol. But yes it from a business perspective it doesn't make much sense to devote a lot of manpower to making competitors more capable.
  - cwyers 9y ago
    Microsoft seems to currently be investing a lot of effort in making developing .NET server apps on a competitor's platform more capable, so I think it's not as cut and dried as that. If you develop a "good enough" LSP server for Kotlin, and have the "best of breed" tools in IntelliJ, then you potentially increase the pool of Kotlin developers, which creates network effects making Kotlin development more appealing, and then you see more IntelliJ use. There can be benefits to making your platform play well with your competitors, if you can still monetize the platform.
    - deleted 9y ago
      [deleted]
- igneo676 9y ago
  It looks like they maintain plugins for other IDEs - notably Eclipse https://github.com/JetBrains/kotlin-eclipse https://github.com/JetBrains/kotlin-eclipse The root cause seems to be the community. Few Kotlin developers use anything but an IDE so there's little motivation to bring tooling to other editors like LSP would

xg15 9y ago

I still don't get it. We could create a parser framework that allowed a client to get some sort of generic AST and reference graph - which would enable all the use-cases of language servers but would also allow more use-cases in the future (e.g. IntelliJ-style inspections or language-aware diffs). Instead, the standard requires running half a dozen processes with an API that doesn't provide anything except the exact data required for a number of handpicked use-cases. Considering that even modern IDEs (again, see IntelliJ for examples) can do more, I don't see how this is a good way forward.

zaphar 9y ago
A generic AST and reference graph that shipped a common denominator of languages is not as easy to do as a set of common operations and queries I think you may be underestimating the feasibility of what you propose.
- teabee89 9y ago
  You mean overestimating the feasibility.
- jblow 9y ago
  You don’t need to do a generic AST. Have it be a protocol ... that runs in-process via an API. Because you know what, that’s what an API is ... a protocol for communicating with someone else’s code. But you don’t have to run extra processes or suffer context switches, and you don’t have to be in the business of debugging distributed systems in order to accomplish any tiny thing. Amazing!!! This whole LSP thing is a mindbogglingly bad idea, brought to you by the same kinds of thought processes that created the disaster that is today’s WWW.
  - klmr 9y ago
    Right, this seems obvious. Any idea why they opted not to go that way? I guess the reason is that the original use-case was VS Code & TypeScript (?) and developing a lowest common denominator API for all clients would mean C, so they would have had to program to a C API even though both the client (VS Code?) and the server (Node?) are running JavaScript. But then maybe the answer should be to provide better C invoke wrappers for high-level languages, not to use HTTP instead of C.

zabil 9y ago

We are in the process of adding full support for language server protocol into our testing tool https://github.com/getgauge/gauge-vscode https://github.com/getgauge/gauge-vscode and it's been a great experience. In the past, we implemented these features for every IDE plugin (IntelliJ, Eclipse, Visual Studio) and it's tough to build, test or debug. With language server, we build all these features in our tools language i.e. Golang, and it works for any IDE that supports the protocol.