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


We're looking at creating a new IDE for Coq, a proof assistant (  IntelliJ seems like a possible candidate for the base IDE.  Several developers have expressed interest in using Microsoft's Language Server Protocol ( to interface from an IDE such as vsCode ( to a Coq-provided server.

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




There is a plugin that allows IntelliJ IDEA to act as an LSP client:


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:


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.


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.


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 (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.


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.





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.


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).


You can use to adapt your LSP server to an IntelliJ plugin with minimum extra effort.


i agree with Fabio Filasieno

you need an official LSP protocol  !!!!!

11 says "With the help of LSPs you will also be able to use other language services in Fleet."

That should allow LSP for fleet - does that indicate LSP support may come to IntelliJ?


LSP support would greatly help my workflow, in particular I'm trying to integrate rome tools in my IDE. Some of the above mentioned solutions don't work on WebStorm.

As the IntelliJ suite is a commercial product, I would expect it to be miles ahead of its open source competition (VSCode). I know microsoft is a juggernaut, but I feel LSP is a much needed feature for a professional IDE.


Correct me if I get something wrong here, but the situation is as follows. Jetbrains has invested a lot into IntelliJ and has all sorts of expertise and conveniences to implement everything using plugins. So this is a good way to provide the best integration and experience, while also not annoying the old guard, the "Apple way" :) The problem is that the IDE accumulated (and keep doing so) a lot of plugins that support a vast number of frameworks and tools. The obvious consequence is that this all has to be supported, and supported, and supported. No matter how big Jetbrains becomes this will overwhelm it (that is not "if" but "when"). So offloading some of the burden by using open and established APIs is a wise idea. If there's fear that JB will lose control over it's product, I may surprise you, but I use IntelliJ and pay money for it, for it's polish not some features other software does not have. That means the search functions should be A LOT faster and reliable than it is now, by the way. This function is more important than, say, any fancy refactorings you offer, because I use it all the time.

Using LSP will likely yield somewhat rougher experience but does enable a lots of usage scenarios. A good example is Rust plugin, made by JetBrains (sic). Which is shipped with severely outdated analyzer so it underlines lots of errors that are not (anymore?). I would like to use the LSP from the Rust version I actually use, but it is impossible to use anything that is not bundled with IntelliJ already. JB does not have time to update that? Surprise, it was their choice to not have it.


Please sign in to leave a comment.