
Language Server Protocol, Rust and Emacs - fanf2
https://christian.kellner.me/2017/05/31/language-server-protocol-lsp-rust-and-emacs/
======
rayiner
[https://lists.gnu.org/archive/html/emacs-
devel/2017-04/msg00...](https://lists.gnu.org/archive/html/emacs-
devel/2017-04/msg00741.html) ("I am urging the GCC developers to work on
implementing the language server."). Interesting statement from RMS, given LSP
is a Microsoft technology, but it makes sense. The software on both sides of
the reference implementation is under a GPL-compatible license. Also, LSP
doesn't expose enough information to allow expropriation of GCC's frontend,
which was RMS's concern with previous such efforts.

Really says something about Microsoft's evolution if you think about it.

~~~
chubot
I'm pretty sure RMS said something to the effect that the ship has sailed with
Clang. There's no longer any point in trying to prevent people from using
proprietary back ends with the GCC front end. If they want to do it, then they
can do it with Clang, so there's no point anymore in trying to "adjust" GCC's
architecture.

I believe a prominent example is NVidia's CUDA compiler. As far as I
understand this is just a modest fork of the Clang front end and a big new
LLVM back end, and it's proprietary.

However Google has developed an open source alternative CUDA compiler, which
is also based on Clang/LLVM:
[https://research.google.com/pubs/pub45226.html](https://research.google.com/pubs/pub45226.html)

Also I would have thought that Clang already has LSP support for C++, but
maybe I'm wrong.

~~~
pjmlp
Another example are the companies selling compilers for embedded development.

Previously they had proprietary compilers or gcc forks that they weren't that
happy contributing back.

Now they can have their proprietary clang forks and don't contribute anything
back.

Plenty of slideware examples at LLVM conferences.

On one side clang was great for improving the whole safety and tooling story
for C and C++.

On the other side, if clang was available to Brad Cox, NeXT would never had
released Objective-C to the community.

~~~
gumby
> On the other side, if clang was available to Brad Cox, NeXT would never had
> released Objective-C to the community.

Actually the Stepstone "compiler" was a preprocessor that generated C (like
cfront was for C++). Brad Cox never worked for NeXT.

The Objective C front end for gcc was written by Steve Naroff at Next. Later
he and I persuaded Jobs that that front end should be merged into the official
gcc tree, and so we (Cygnus) worked with NeXT to get merge them and,
amazingly, produce Objective-C++ in the process.

Jobs was focused on the goal. When NeXT (and later Apple) were underdogs he
was happy to embrace open standards (e.g. JPEG, MPEG, MPEG-3...) when it would
help and outside proprietary standards when he thought it was needed (e.g.
paid the rtf license).

~~~
pjmlp
Thanks for clarifying how everything went, and correcting my "what if".

------
corybrown
As a vim user, I'm very excited about LSP. Neovim (close enough) may add
native support, which would be great:
[https://github.com/neovim/neovim/issues/5522](https://github.com/neovim/neovim/issues/5522)

It's possible to do a lot of the nice IDE features in vim (and I'm sure emacs)
today w/ all sorts of contortions, but a standard way to get this done would
be amazing.

------
dilap
> On the initial opening of a project it will hog the CPU and spin up the fans
> but that doesn't last too long. Sometimes it completely hangs Emacs. Nothing
> that killall rls followed by a M-x revert-buffer can't fix.

Yep, sounds like emacs. (I use emacs, but my god is it a horrible collection
of half-broken hacks. Still the most useful editor going, though. If anyone
wants to fund me, I'll start a project to make an editor that combines the
flexibility of emacs with a rigorous, ruthless obsession with speed and
correctness. :)

~~~
Analemma_
emacs: Emacs Makes Any Computer Slow

Boy it's been a while since I've broken out that one ;)

~~~
ftlio
It's as good a text editor as it is a terrible operating system

(to flip an old one on it's head).

------
kuschku
The Language Server Protocol is flawed already in its concept, as this article
[https://perplexinglyemma.blogspot.de/2017/06/language-
server...](https://perplexinglyemma.blogspot.de/2017/06/language-servers-and-
ides.html), which was also on #1 of HN before, argues.

It instead proposes to have the language server expose the entire AST and
environment that is available at each point, and have the IDE uses that for
autocompletion, as this is far more powerful than what is currently doable
with LSP. (Currently, the editor just transmits cursor position and content to
the LSP, which then does all the highlighting, autocompletion, etc. This is
not only less configurable, and less consistent, but also less usable, as
often the LSP isn’t able to offer as smart autocompletions)

Many IDEs, such as the JetBrains IDEA platform, do exactly this with their
language plugins.

~~~
Analemma_
I mentioned this at the time too: I think this was a deliberate decision by
Microsoft and it is not a deal-breaker. LSP is a Minimum Viable Product that
was deliberately kept simple to encourage uptake and not spook people away.
Once people are comfortable that it is a good idea and not an EEE play by
Microsoft, version 2.0 could be upgraded to support things like ASTs.

~~~
kuschku
> version 2.0 could be upgraded to support things like ASTs.

That’s called "you can create an entirely new API that’s entirely different,
but might use the same name".

That’s the issue here, LSP is so fundamentally flawed you’d have to scrap it
entirely to support what is needed for a real IDE.

------
IshKebab
Just a warning to anyone expecting auto-completion in Rust to be anything like
C++ or Java, or even Typescript. It isn't close to that yet.

~~~
vvanders
To counter that I've got a pretty moderate size Rust project that uses hyper,
websockets, glium and a bunch of other libraries. RLS + VSCode has been
incredible solid.

It's come a long way in the last few months, I'd recommend giving it a shot
again.

~~~
bpicolo
The lack of code-inlined error reporting is still a big miss (unless I'm using
the extensions wrong somehow). It's also pretty complicated to get right in
rust as the errors tend to link through to multiple files for lifetime issue
and such. I started tinkering with a version of this yesterday for vscode.
Hoping to get a sane v0 off the ground.

Would be cool to have a linter that can run file-by-file as well, though
that's tough for clippy as a compiler plugin it seems? Maybe just hacking it
to only report on a particular file would work.

~~~
vvanders
> code-inlined error reporting is still a big miss

Do you mean errors next to lines? If so that works today in the RLS variant.
You get a red highlight and can mouse-over for details.

~~~
bpicolo
For me this only seems to work in the legacy racer mode (in
[https://github.com/editor-rs/vscode-rust](https://github.com/editor-
rs/vscode-rust)). Have you had success in RLS mode? RLS just spits stuff into
console. =|

~~~
chillee
I've gotten RLS mode to work for VSCode personally. I've had issues with
larger projects, but for smaller projects it seems to work fine.

------
ilurkedhere
How does it compare with racer-mode? Does it have roughly the same
functionality or is one a subset of the other?

