Same here. Anyone know if eglot is "better" than lsp-mode? Or was it just picked because of some licensing reason? I was under the impression, but I may be wrong, that lsp-mode was somehow better than eglot.
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?
Having alternate implementations is never a bad thing.
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.
> It took me more time to declutter the amount of stuff it put on screen than what it took to setup.
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-mode does integrate with eldoc, you just need to configure what it shows in the minibuffer, eg. to turn of the excessive clutter, set these to nil
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 much
At least for web development I believe eglot is strictly worse. It does not support running multiple servers (e.g. tsserver and eslint-ls) (https://github.com/joaotavora/eglot/issues/976) which is supported by lsp-mode and neovim's built-in lsp client. Also, it does not have any equivalent to dap-mode which is lsp-mode only. Although worth noting dap-mode is currently useless for js (https://github.com/emacs-lsp/dap-mode/issues/369).
Why wouldn't you want the lint error to be highlighted right as you type the code?
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!)
> Why wouldn't you want the lint error to be highlighted right as you type the code?
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 wouldn't you want the lint error to be highlighted right as you type the code?
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.
Presumably eglot was picked because it's by far the more emacsy LSP client. It does most of its user-visible job by integrating with other built-in packages, like Flymake, ElDoc, project.el, and most importantly xref. Integrating lsp-mode would make much less sense, since you'd be integrating an alternative universe of packages that already have built-in analogs.
Are you sure? I could have sworn my lsp-mode uses at least flymake, xref, and projectile (which I use over project.el) as well, and I don’t remember making a custom setup in that regard? Not in front of emacs right now, but very sure. Maybe that was different in the past?
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.
I just remember a zillion weird popups with lsp-mode, which is all UI that isn't built in to Emacs. But also: Projectile isn't built into Emacs. Project.el is. The lsp-mode hovers are bespoke; eglot just uses ElDoc. lsp-mode wants you to use flycheck; flycheck isn't built into Emacs. lsp-mode can use xref, but it also has its own thing. lsp-mode has its own header and modeline goo. It goes on like that.
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.
Yes I had exactly the same experience, maybe 3 years ago? Installing lsp-mode resulted in an overblown UI with all sorts of gadgets; it looked like an attempt to create an "IDE experience" in Emacs, and so I ran away, used eglot for a few months, and then ended my 20-year Emacs run and switched to VSCode. (Apart from magit -- of course I do still have an Emacs instance running.) But it does sound like people are saying that lsp-mode got rid of the tasteless stuff. And since Eglot development has now moved away from GitHub to a combination of unpleasant mailing lists and unfashionable issue-tracking apps, I wonder whether it will stand a chance in the future competition.
Sorry, I’m just not sure most of that is true anymore. How long ago was your experience? I remember bouncing off lsp-mode into eglot years ago as well for similar reasons, but nowadays it just seems totally different to me.
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.)
I thought this would annoy me, since I had a custom flycheck setup for years and years prior to eglot, but I haven't noticed any differences in my workflow; it just works.
It's been an issue since before it was the latest stable version, and if the packages needed that version they should be declaring dependencies on it. And project.el is still today marked experimental, so this will probably happen again.
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.
The main difference is that eglot doesn't support the complete set of LSP features yet, but those it does support are better integrated with the existing Emacs codebase and featureset. It's very much a work in progress, not aiming to be a self-contained thing like lsp-mode.
I used lsp-mode for a while and then switched to eglot. The reason was that lsp-mode has quite a lot of dependencies including helm and hydra. This can be inconvenient when you use their alternatives likes the vertico-corfu stack. I didn't want more than one extension of the same type in my configuration. eglot uses native emacs APIs for completions and tooltips. This integrates very well with vertico and corfu.
> 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.
lsp-mode does not depend on helm or hydra, or anything else really. There are optional packages that allow it to work better with those systems though.
Lsp mode depends on neither helm, nor hydra. I think there are some utility things that can use helm, but as far as I remember it that didn’t require that helm was set up for anything else and it has never conflicted with anything else I use.
I've used both, or rather, tried using both - lsp-mode never quite worked for me, whereas eglot is rather simple in comparison and easy to set up.
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.
> Same here. Anyone know if eglot is "better" than lsp-mode? Or was it just picked because of some licensing reason?
I 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.
> First thing which happens is that eglot complains its can't find a language-server for the major-mode I'm working in now
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?