[fiddlerwoaroof]

I know this is how a lot of people think of the text editor/IDE divide, but it’s just not true anymore: for specific languages like Clojure or Common Lisp, emacs has plugins that provide all the essential features of an IDE with minimal fuss. For JavaScript, VSCode or tide-mode for emacs have, in my experience, significantly better code intelligence than WebStorm. The only languages IntelliJ is better at than the competition, IME, are Java, Kotlin and Scala: and, even in these cases, the LSP tooling is catching up fast.

[aschatten]

> emacs has plugins that provide all the essential features of an IDE with minimal fuss

I vehemently disagree. There is no such thing as minimal fuss in emacs, especially when it comes down essential IDE features.

> for specific languages like Clojure or Common Lisp

Common Lisp is esoteric language at this point, not relevant here, IMO.

[pwm]

I agree. Which language you use defines which editor/ide suits it best.

[mcdevilkiller]

What about Resharper/Resharper++?

[thu2111]

Well, obviously a text editor built on top of Lisp is going to be pretty good at editing Lisp-based languages like Clojure. Emacs is pretty poor at everything else though. I remember trying to get it to do even basic completions in C++ beyond hippie-style completions and it just couldn't do it no matter how many packages or servers it had to help it. That was some years ago though, but emacs develops slowly so I doubt it's changed.

That said, the tiling WM features it has are pretty good.

"LSP tooling" for Java/Kotlin/Scala doesn't exist as far as I'm aware. I'm sceptical about LSP stuff anyway. In an IDE performance and latency really matters. IntelliJ plugins have direct heap access to the AST and editors so they can rapidly explore the code, add annotations etc. Java adds some overhead but it gets lower every year, they just never stop optimising the JVM, and serialisation/context switching is gonna add a lot back. Especially as you'll really want to be writing language servers in high level languages anyway. There's no justification for writing such a thing in C++ or Rust.

[Qerub]

> "LSP tooling" for Java/[…] doesn't exist as far as I'm aware.

There's https://github.com/eclipse/eclipse.jdt.ls. It's used by Visual Studio Code's Language Support for Java (https://marketplace.visualstudio.com/items?itemName=redhat.j...).

[fiddlerwoaroof]

I use this with emacs, and it works pretty well: it was built for Eclipse, but it’s well-integrated into lsp-mode and, more or less, “just works”.

There are also Kotlin and Scala LSP servers that work. The servers themselves can be a bit annoying to get working, but the emacs integration “Just Works”.