
Introducing SourceKit-LSP - mbroncano
https://forums.swift.org/t/introducing-sourcekit-lsp/17964
======
peterkelly
I've recently started adding support for the Language Server Protocol (LSP) in
a language project I'm working on, and it's a godsend. If you're not familiar
with it, it's basically an editor- and language-agnostic protocol for
implementing typical IDE behaviours like error highlighting, code completion,
hover information, find references, etc. It solves the M*N problem in which
every language would have to have a separate plugin tailored towards the APIs
of every editor; now you just write either to be LSP compliant and it takes
care of 90% of integration effort (writing the language server itself of
course is still a lot of work).

Although it's still necessary to do a little plumbing work to integrate into
each editor, this is largely boilerplate that differs little between
languages. Most of the functionality resides in a JSON-RPC server implemented
in your language of choice.

I've found it particularly useful when used in conjunction with the Monaco
code editor [1] (the engine that powers Visual Studio Code), along with a
supporting plugin for talking to a remote LSP server [2]. These make it
possible to build interactive coding environments into a web app which include
many of the typical editing features you're used to in IDEs.

It's great to see Apple along with other language vendors adopting this as a
standard.

[1] [https://github.com/Microsoft/monaco-
editor](https://github.com/Microsoft/monaco-editor)

[2] [https://github.com/TypeFox/monaco-
languageclient](https://github.com/TypeFox/monaco-languageclient)

~~~
alexashka
I think it's a positive, but I also question what the point is.

What I'd like, is a better IDE, not an IDE that can provide features I've had
for 30 years, for 30 different languages, in a consistent manner.

I dont' _want_ 30 languages, and 1 basic lowest common denominator ide. I want
2-3 languages, and excellent ides that push the boundaries of the unique
features of each language.

~~~
zapzupnz
It's not like those sorts of IDEs don't exist. Swift and ObjC have Xcode, C#
has VS, Java has IntelliJ, etc.

> What I'd like [...] not an IDE that can provide features [...] in a
> consistent manner

How is providing consistent support for many languages a bad thing? This I
don't understand. People love their tools, for better or worse, so why should
being forced to change tools be the _only_ workflow?

Your beloved one-IDE-for-a-couple-of-languages already exist and have done for
years, so no need to be a Grinch.

~~~
cellularmitosis
> excellent ides that push the boundaries of the unique features of each
> language

> Swift and ObjC have Xcode

Hard disagree that Xcode falls under the category of "excellent". Is this
parameter a concrete type, or a protocol? Sure would be nice if they were
color coded... that's pretty low-hanging fruit.

But that's looking at the trees. The important point is that the forest is
rubbish. It is 2018 and our developer experience is still fundamentally
oriented around the idea of _individual text files_. This has been the
fundamental unit of organization for 50 years.

A typical developer task might require examining 7 or maybe 12 small pieces of
code, all of which are in different files. If this were in the physical realm,
you'd grab these pieces and plop them on your desk, arrange them this way or
that, think about them for a while, play with a few ideas for possible
changes, settle on one, and then start implementing the changes.

About the only affordance which Xcode offers to facilitate this sort of work
is command+click to jump to a definition.

I literally resort to _taking screenshots of code snippets_ and arrange them
in diagramming software in order to think through a problem. Why is my IDE not
facilitating this sort of work?

Edit: though if we are stuck on text-file-oriented program organization for
the time being, there's still a lot which can be done to improve upon that,
e.g.
[https://youtu.be/0Vq2rcjWbTc?t=1429](https://youtu.be/0Vq2rcjWbTc?t=1429)

~~~
still_grokking
There is a nice solution for this problem. I really don't know why it did not
take of. Maybe nobody knows about it?

[https://www.uni-
ulm.de/en/in/pm/research/projects/inline.htm...](https://www.uni-
ulm.de/en/in/pm/research/projects/inline.html)

All this "code portal" features of Inline should be found in any modern code
editor! But nobody implemented them in any of the usual IDEs until now to my
knowledge. That's a real pity.

~~~
peterkelly
That looks amazing and has given me some ideas for my project. Thankyou!

~~~
still_grokking
Nice to see someone noticed this one. The ideas are indeed great, so spread
the word. Really want to see this features in every code editor in the future.

------
sqs
Very excited to see this. We will use this project to add Swift support to
Sourcegraph soon so you can get hovers, go-to-definition, find-references,
etc., when browsing code on
GitHub/GitLab/Bitbucket/Phabricator/Sourcegraph/etc.

[https://github.com/sourcegraph/sourcegraph/issues/979](https://github.com/sourcegraph/sourcegraph/issues/979)

------
KingMob
LSP seems like an interesting concept, but it would be nice if it included
more support for REPLs. I'm thinking of things like "evaluate highlighted
section" or "recompile function under cursor".

------
sdegutis
> _SourceKit-LSP is built on top of sourcekitd 23 and clangd 23 for high-
> fidelity language support, and provides a powerful source code index as well
> as cross-language support._

That's pretty much been Apple's motto for a while: need language support for
anything other than compiling the language, like IDEs or documentation
generation? Why not add it _directly into the compiler?_ This has pros and
cons, but personally I like the direction Microsoft has gone: rewrite
everything in JavaScript (actually TypeScript) so that it's super portable and
more easily embeddable.

~~~
geodel
Seems Apple as a company is not totally hijacked by Javascript people. I am
happy that Apple took some stand against Java/Flash/Javascript when it
interfered with quality of user experience.

~~~
nerdponx
I think in this case Javascript just happens to be the most portable
programming language right now.

~~~
azinman2
Python and Perl too....

~~~
nerdponx
Python and Perl don't (yet) run in a browser. Also Javascript is probably
somewhat "faster" (than CPython, at least) due to its JIT.

~~~
lizmat
Perl 6 runs on Chrome:
[https://perl6.github.io/6pad/](https://perl6.github.io/6pad/) Other browsers
will follow soon.

