I can't really compare because, well, I don't use JetBrains IDEs at all, but for supported languages, emacs-lsp does provide features like code completion, lookup, inline documentation…. It is the single biggest improvement to Emacs for me since I've started using it a long, long time ago. I can tell that it works very well for at least Python and Rust. I remember TypeScript support looked nice too, though I don't do much TypeScript these days.

edit: screenshots / screencasts: https://emacs-lsp.github.io/lsp-mode/page/gallery/

It's not bad for Go either. The only issue is that gopls is still considered alpha, so it's not the most stable thing out there, but that's not Emacs's problem.

I've been using gopls with lsp-mode for a while and it's been working great, I haven't had any stability problems.

Very true - gopls has come a long way. I should note I use it every day in lsp-mode when I'm writing Go. Hiccups are much less common now than, say, a year ago.

Consider trying Emacs 27.1 with the Jansson library to help with JSON parsing if you're using an LSP-based approach in Emacs. (Apparently one of the reasons that it's sluggish is because the comms between Emacs and the corresponding language server are done in JSON, and previously Emacs' JSON parsing was a bit slow--libjansson was incorporated to speed that up). I have not used JetBrains so I don't have that comparison, but I use this Emacs arrangement with C# and have been very happy with its autocomplete/jump-to-definition/etc. capabilities. (I have used it with Python and JavaScript as well with a bit less success, but I think that is mainly because I haven't managed to get my environment configured quite right for it to be able to find everything, so that's my own shortcoming and I'd expect to have similar issues in any other editor ;) )

I'm running a self-compiled emacs 28.0.50 on osx. Part of me wants to try recompiling and/or using a homebrew formula for latest emacs just in case I did something wrong in the compile process.

The emacs 27 speed improvements is actually what inspired me to try and get a working editor out of emacs again. Previously I had something that was usable but not great for javascript.

> achieving parity with JetBrains in code completion/code searching?

The language server for Rust that I prefer was written, and is maintained by, a JetBrains employee. For C/C++ it's hard to beat ccls, and for C# there's omnisharp-roslyn which is, again, hard to beat.

Otherwise, with dumb-jump I get superior jump-to-definition than JetBrains.

I haven't used JetBrains for a few years but it was always pretty slow (i.e. slowed down VS notably and nearly globally) for c++ at least - so perhaps something inherent in the parsing as well though clearly that could be improved.

I've never found a fully satisfactory c++ setup, but always thought things like e.g. slime worked well.

> I've never found a fully satisfactory c++ setup

My preferred stack is: Emacs + lsp + ccls + dumb-jump + rg + projectile + dap

It's still not perfect, but it's the best I can do.

I find it, and VSCode and Visual Studio, _astonishingly_ slow compared to Emacs + dumb-jump + rg/ag.

Depends on what language you need to support.

For python, elpy pretty much "just works" (some kicking required). It has a built-in diagnostic helper that will tell you what packages you're missing.

For anything supported by clang, company-clang or clangd work quite well.

For everything else, rtags/gtags or similar is the way to go. It uses a superficial understanding of the files, so black magic (e.g. putting `int=str` at the top of your python file) will confuse it, but it's generally good enough.

Even VSCode is nowhere near Jetbrains. Their IDEs are rather heavy though. Doom's python+lsp works well enough for me. (My config https://github.com/NightMachinary/doom.d)

I appreciate you linking your config. I made one or two changes to my own config and it seems to have improved.

I don't quite understand why this works without +lsp in the python language configuration. I also don't really understand the significance of lsp-mode versus eglot or whether or not this change made a difference. But -- these changes make my config a lot easier to use and build off of now.

Just yesterday I think I achieved such parity. Everything is working wonderfully (though, again, it's only been one day, so I can't speak to longevity).

I'm using the native-compiled branch of emacs28 on macOS (see https://github.com/jimeh/build-emacs-for-macos). I'm using spacemacs, so I don't know how helpful my config will be, but for python I'm using lsp-mode with pyright on the backend.

I've been using emacs for ~2yrs, and there were a lot of things I loved about it, but code completion has always been mediocre until now.

As I mentioned in another comment here, somebody gave a lightning talk about lsp-java [1] at Emacs Conf last year, which I thought looked promising.

[1] https://emacsconf.org/2019/talks/19/