
Langserver.org – A community-driven source for Language Server implementations - gitgud
https://langserver.org/
======
josteink
I have to say that list has gotten waaay longer since last time I saw it.

LSP really has been a massive success, and despite being made by MS, has been
one of the main reasons I’ve been able to keep using Emacs and not migrated to
other more IDE-like editors.

MS deserves som serious credit here for being one of the few players willing
to think in _protocols_ these days. Protocols vs products makes a big
difference.

~~~
_bxg1
It's truly one of those I-can't-believe-nobody-thought-of-this-before ideas.
And beyond the obvious benefits to developers' experience, it's also a huge
boon to smaller language projects. If you build a new, open language and don't
have the backing of a huge company, you definitely don't have the resources to
integrate it directly with every editor someone might want to write it in. But
you might be able to put together a single language-server.

~~~
mikewhy
There was (and still is) YouCompleteMe for Vim, which is the idea of a code-
completion server with editor plugins, so it's definitely a thing people had
thought of.

Microsoft really took the ball and ran with it, and I'm very grateful for
that.

------
sytse
It seems that Language Server Index Format (LSIF)
[https://code.visualstudio.com/blogs/2019/02/19/lsif](https://code.visualstudio.com/blogs/2019/02/19/lsif)
is the successor to the Language Server Protocol (LSP). LSIF supports code
navigation without having all source code files available on a local disk like
LSP requires.

~~~
mikewhy
Maybe "successor" isn't the right word, as per the linked article:

> The goal of the Language Server Index Format is to augment the LSP protocol

~~~
lostintangent
Correct! We designed LSIF to be a complement to LSP. LSIF is basically a way
to persist language server state, so that LSP queries (e.g. what are the
definitions for this symbol?) can be answered without needing an active LSP
server running.

Among other things, LSIF enables rich IDE navigations on remote codebases,
where’s its much more scalable to perform those queries using indexed data vs.
spinning up language servers. Here’s the blog post where we first announced
the work we were doing, that led to the creation of LSIF:
[https://code.visualstudio.com/blogs/2018/12/04/rich-
navigati...](https://code.visualstudio.com/blogs/2018/12/04/rich-navigation).

------
bobajeff
It's cool that Kate almost has full support for LSP.

Update: here's a post I've found about it:

[https://kate-editor.org/post/2020/2020-01-01-kate-lsp-
client...](https://kate-editor.org/post/2020/2020-01-01-kate-lsp-client-
status/)

I'd love for Geany to also either get support built-in or as a plug-in.

Also noteworthy is CodeMirror and JupyterLab working on support.

------
_bxg1
Quick piece of feedback: the big table with all the languages could use a
color other than red (gray?) for "Not Applicable". For example, I assume
that's the reason JSON is missing "Jump to def", "Find references", etc.

------
st3fan
THe SourceGraph server for Go is deprecated in favor of 'gopls'. This is
documented on the sourcegraph github page.

~~~
guessmyname
The website is maintained by SourceGraph so of course there’s going to be some
bias.

That being said, the website is editable on GitHub [1] so people can submit
fixes if needed.

I’ve been using “gopls” [2] since Feb 2019 and I’m very happy with the
functionality.

Rebecca Stambler, Heschi Kreinick, Muir Manders and the rest of the team are
doing a wonderful job.

I encourage everyone to join the #gopls channel in the Gophers Slack group [3]
to follow the updates.

[1]
[https://github.com/langserver/langserver.github.io](https://github.com/langserver/langserver.github.io)

[2]
[https://github.com/golang/tools/tree/master/gopls](https://github.com/golang/tools/tree/master/gopls)

[3]
[https://invite.slack.golangbridge.org/](https://invite.slack.golangbridge.org/)

~~~
sqs
Sourcegraph CEO here. We fixed it and added gopls. Sorry for the mistake. It
is not bias. We are very happy that Google made gopls. It is not our core
product (universal code search is), and Google building gopls means we can
focus more on our product. :)

------
mthoms
Given this, I wonder what the future holds for JetBrains. They've made a good
business out of providing standalone solutions for the more popular languages.

~~~
stefan_
The same thing as always, making kick ass IDEs and actually working, robust
productivity tools?

A few rows down someone is praising "language servers" as some sort of
Einstein discovery. I'd argue _that was the easy part_ and they are rapidly
learning about the difficulties involved, and the way is paved with auto-
generated configuration pages wrapping json.

------
dang
A thread from 2017:
[https://news.ycombinator.com/item?id=15711604](https://news.ycombinator.com/item?id=15711604)

------
mikewhy
Another thing I really like about LSP is that formatting and linting are
built-in concepts. Using something like [https://github.com/iamcco/diagnostic-
languageserver](https://github.com/iamcco/diagnostic-languageserver) you can
bridge existing command-line tools that only support stdio into your editor of
choice.

~~~
realharo
It is still missing semantic highlighting (e.g. a local variable has a
different color than a function parameter), although looks like things are
finally moving on that front.

[https://github.com/microsoft/language-server-
protocol/issues...](https://github.com/microsoft/language-server-
protocol/issues/18)

