Also I wonder: if eglot is now part of Emacs, is there any incentive for the lsp-mode devs to keep working on lsp-mode?
I got quite weary of hacking on my Emacs so I switched to eglot and had zero trouble since.
Sorry for lack of context, I am not shilling for eglot at all, it's just that I have a huge "make it your own by hacking!" fatigue these days.
lsp-mode does 'more' (and there's also an auxiliary package, dap-mode, for debugging), but I guess is somewhat more brittle because of this. dap-mode I do use, by the way (for python mainly) - functionality-wise it's my favourite debugger available in Emacs.
eglot further has a single developer who already assigns copyright to the FSF (and developed other packages, like flymake, which are already part of emacs), so it has that going for it as well.
I spent some time to get lsp-mode working earlier this year. It took me more time to declutter the amount of stuff it put on screen than what it took to setup. In fact they have a page about this https://emacs-lsp.github.io/lsp-mode/tutorials/how-to-turn-o...
After turning off 2/3 of these, the experience has been stable and supports almost everything. I experienced clangd crashes, but lsp-mode was always able to recover. I'm not too fond of the reliance of treemacs (don't particularly like treemacs behavior in general).
I just tried briefly eglot. It worked right out of the box, and the default "output" on screen seems to match what I left enabled for lsp-mode, which seems sane to me. xref integration seems to highlight methods with cc-mode (lsp-mode doesn't).
Some lsp features are missing. For example I couldn't find an equivalent for "incoming call hierarchy". Not a show stopper.
I would need to spend some good time to see which one provides less overhead, for example.
Same.
lsp-mode is great if you want to use a distraction-filled UI that doesn't integrate with anything else in the Emacs world. My first thought on trying it was "you're showing me three epitexts by default and yet none of them are running through eldoc." A large number of people seem to want that, god help them.
lsp-signature-render-documentation nil ;ridiculously shows entire doc in mini
lsp-eldoc-render-all nil ; if t, shows all hover info in eldoc - too muchI just checked, and both are licensed as GPLv3. I guess it could be this copyright-assignment thing?
Either way because of this move, I decided to try eglot over lsp-mode.
First thing which happens is that eglot complains its can't find a language-server for the major-mode I'm working in now... And it does *not* offer to automatically install one.
Based on this alone, I would say for OOB experience lsp-mode still seems leaps and bounds better.
That was also my experience. Eglot wasn't able to use the installed vscode-json-languageserver for editing JSON instead insisted that typescript is is not installed.
lsp-mode worked worked without any configuration out of the box
> Also I wonder: if eglot is now part of Emacs, is there any incentive for the lsp-mode devs to keep working on lsp-mode?
I'm pretty sure that some people will stick to lsp-mode. There are a few builtin extensions which I replaced with more popular external packages (eg: projectile vs project.el). So, I think the lsp-mode devs should keep at it.
https://emacs-lsp.github.io/lsp-mode/page/installation/#vani...
Always curious of why you prefer one of the other. Any major thing you prefer projectile? (only ever used project.el here and was satisfied)
Similarly, I'm using ivy, first time I see vertico which looks similar.
Try `M-x ffap' whilst point is on an include directive's filename, or `M-x ff-find-other-file' to jump between C/H header files.
They will be stuck on older versions and experience those problems as current problems.
Version management in Emacs is hard but a) lots of the community runs Emacs versions much older than 1y old and at least few years of compatibility is (used to be?) a strong cultural norm, b) it's common to offer fallbacks to e.g. `locate-dominating-file` or similar primitive cases especially when using relatively new features, c) I don't think project.el is very good in general.
I switched from eglot back to lsp-mode a while ago, but I don’t quite remember why unfortunately. I think lsp-mode “did more” or something like that, and seemed to have changed for the better.
None of this is bad. These aren't critiques of lsp-mode. But they're definitely reasons why it would make sense to integrate Eglot, which prioritizes integrating with Emacs built-in libraries.
The actual critique of lsp-mode I would make is that I bounced from lsp-mode at least 3 times trying to get things working, and things would always be ok for like a couple days and then I'd lose 30 minutes to debugging and ultimately just turn it all off so I could get on with my day. I enabled Eglot once, with like 10 lines of use-package, and haven't touched it since.
I think that may be lsp-ui, not lsp-mode, but I might be mistaken.
I’ve never used anything but xref in lsp-mode, I rely on xref a lot. I wasn’t even aware that lsp-mode has, or had, something bespoke there.
I use flymake, not flycheck, I don’t think I had to configure that.
projectile is just my personal preference because I'm used to it, the manual says it integrates with either project.el or projectile.
I remember the weird popups you mention from my first lsp-mode trial. I don’t know where they’re gone, nowadays it’s just text in the buffer. (But I don’t know whether that’s ElDoc or not.)
gopls has staticcheck and govet warnings; they are quite useful as you're typing in your code. (Though sometimes a little aggressive. My favorite is highlighting an if statement as an "empty branch" before I've had time to type in any code. I'm working as fast as I can, Mr. Linter!)
eslint's flymake integration can do this without any language server commitments. LSP maybe offers some performance advantage - but IMO that says more about eslint than LSP or flymake.
Why do you think you need to involve an LSP for that?. ESLint, as most linters, can take their input from stdin. That is exactly how the eslint-flymake[0] works. Lint on buffer contents, not file on disk. No JSON RPC involved.
Landing into Emacs core was never a goal for lsp. So it wasnt a choice between eglot vs lsp. It was eglot, yay or nay.
I never tried Eglot simply because the name made me think it was less serious.