IntelliJ support for Language Server Protocol (as a client)?

Answered

We're looking at creating a new IDE for Coq, a proof assistant (https://coq.inria.fr/).  IntelliJ seems like a possible candidate for the base IDE.  Several developers have expressed interest in using Microsoft's Language Server Protocol (https://github.com/Microsoft/language-server-protocol) to interface from an IDE such as vsCode (https://code.visualstudio.com/) to a Coq-provided server.

Does IntelliJ have any support for LSP, plans to support it, plugins for LSP, etc?

Thanks,

Jim

10 comments
Comment actions Permalink

There is a plugin that allows IntelliJ IDEA to act as an LSP client: https://plugins.jetbrains.com/plugin/10209-lsp-support

1
Comment actions Permalink

There is also a stable IntelliJ language client library which allows any IntelliJ plugin to connect to the language servers and use the features seamlessly: https://github.com/ballerina-platform/lsp4intellij

2
Comment actions Permalink

A community-provided plugin is nice, but I think plugin providers are more wary to base their support on that; what if the person stops development or support?

It would be much nicer if Jetbrains themselves can provide LSP support so that other plug-in providers can have the confidence that it will be supported in the future.

6
Comment actions Permalink

Both existing plugins for LSP support are open-source, so if the original developer stops development or support, it's fully possible for plugin developers who use that code to continue development or support by themselves.

-4
Comment actions Permalink

Yes, of course, that is always the case with open source.

But the person who wants to provide a language plugin might want to focus only on that, and not want the responsibility of maintaining the LSP plugin as well.

But on the other hand, if the LSP functionality is supported by Jetbrains themselves, it frees language plugin authors to focus on providing the language functionality, with the guarantee of future support.

The XText plugin would still be maintained if this had been the case: see https://plugins.jetbrains.com/plugin/8074-xtext. (Granted, they used a different plugin that is no longer maintained, but it comes back to my point that if the LSP support was guaranteed, they would still be there).

I believe LSP support is a big reason why there are many more language plugins available for VS Code. Would be nice if one could lure them to the IntelliJ platform.

6
Comment actions Permalink

Hi Dmitry,

from my point of view it's not the LSP that is interesting, but the fact that there is formal specification of the protocol to comunicate with the IDE. As a compiler writer, with VSCode/LSP I can expose the compiler data to the editor by writing code in the language I'm designing or C.

With IntelliJ I can't I have to write it in Java.

For this reason I'll adopt VSCode/LSP instead of the JetBrains products; and its a shame since I actually use CLion to write my code, but my compiler offers an LSP for VSCode to consume.

In my opinion what you need to do is define an LSP protocol for the intelliJ platform even if it's different from the LSP of VSCode. I love JetBrains; I'm really a fan; I used IntelliJ IDEA 1.0 and since then JetBrains products have been part of my daily life.

But I think this is BIG mistake: you need a competing protocol, designed for performance and tailored for your platform, and officially supported and maintained.

Without it I'll "code" my language with CLion, but I'll "use" my language on VSCode; but I would really like to use the IntelliJ platform instead of VSCode and I don't what to write Java code to write the plugin as I'd rather use C for performance (because of SIMD and memory layout control). 

I think you need an official protocol not loose market share and from my point of view I don't care if it's Microsoft's LSP or JetBrains LSP, but you do need one and considering the quality of your work, you'll probably do it better than Microsoft.

 

 

 

6
Comment actions Permalink

A LSP would be beneficial as the learning curve is shortened & the ergonomics of making tooling libraries & automation scripts is improved. Having to learn & use a Java based implementation for the tooling, instead of the programmer's preferred platform (like Typescript, Rust, or WASM), is impractical in many cases.

Microsoft is investing heavily on the Low Code ecosystem. Having a LSP seems like powerful foundational component to this approach.

2
Comment actions Permalink

Microsoft VS Code is definitely leading the way here. As my team develops a configuration DSL, it'd be great for us to enable our users to edit their configuration in an IDE, with IntelliSense. I could see us providing that via LSP, but it wouldn't make sense to do a lot of custom work specifically for IntelliJ (that is, without an LSP path).

0
Comment actions Permalink

You can use https://github.com/ballerina-platform/lsp4intellij to adapt your LSP server to an IntelliJ plugin with minimum extra effort.

-3
Comment actions Permalink

i agree with Fabio Filasieno

you need an official LSP protocol  !!!!!

1

Please sign in to leave a comment.