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".
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.
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.
> 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 =)
(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... )
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.