Eglot is written by a regular Emacs contributor and maintainer, and as a result is much higher quality code. lsp-mode is written by volunteers on Github without a lot of Emacs Lisp experience (it shows), the code is pretty bad at places, definitely over-engineered and I wouldn't recommend it.
Even if the things you say about lsp-mode are true (which I don't think they are), lsp-mode has many features that eglot has no alternative to at all.
I also feel that lsp-mode's features are higher quality overall, with the downside of depending on packages and features not built into emacs itself. An example of such a feature is lsp-mode's project integration, it uses projectile which is much more powerful and useful than the built in project.el. Another example is using flycheck instead of flymake for on-the-fly diagnostics.
I would not say either package is better than the other because they are so different, and have such different philosophies. Eglot is much more minimal and tries to use native emacs features when possible, preferring minimalism over features. lsp-mode brings in a lot of features and prefers to use third party packages instead of built ins.
I used eglot for a little while before trying lsp-mode and decided that I personally prefer lsp-mode overall, with both being great options. I would recommend anyone curious to give both a try and decide for themselves.
lsp-mode maintainer here. I may assure you I know how the traditional elisp is written and I simply dont like it. Happily lisps allow you to write in different styles I can tell you that a lot of people find lsp-mode's source code more readable(in addition to being faster). To give an example of the differences in the mindset: Emacs core developers have `first`, `second` and `rest` deprecated in favor of `car`, `card`, and `cdr`. I will do the opposite.
Of course, there are problematic sections (so do eglot) but keep in mind that `lsp-mode` and emacs-lsp organization has ~10 times more code and contributors.
Hey, total aside: thank-you. Thank-you for helping to make Emacs competitive again. If not for lsp-mode I wouldn't still be using Emacs, even with 30y+ of enjoyment from it.
Staggering to imagine a developer using emacs would use some random community package corner-case function to install and keep updated an important package written in the same language he programs with.
These are the same developers who want a good out-of-the-box experience. It seems to me that lsp-ui is meant to replicate the features of VSCode, it's not surprising the same developers want to make it easy to install language servers.
I'd prefer to install pyright myself in my own node virtualenv rather than having it dropped into ~/.config/emacs/.cache/lsp/npm/pyright, but I understand why autoinstall is an attractive option.
What would they do when it inevitably breaks? Google won't bail them out on this one. What if there's a security issue with the server, are they going to have it up to date? Are they going to cry wolf online about how this ancient editor doesn't work for them? I understand some may want those poor souls locked into vscode to see the light, but this isn't the right way to do it. Emacs is great because it's rock-solid and incentivizes good practices, this is the complete opposite.
It uses the package manager of the system, or the one native to the language, to install servers. Ie, it uses nuget to install omnisharp. The same tools are used to update the servers.
Feature regressions and security holes from those sources will effect everyone, even those installing manually.
the installation isn't so much a thing as the "guarantee" that the installation happens in the place Emacs expects it to be, without having to futz around with PATH and the like.
It's not that it's hard, but it's Yet Another Thing That Can Go Wrong.
lol. I've been developing code with emacs for 25 years and I'm fine with this and would be annoyed if I needed to figure out how to install every language server for every language I use.
With all due respect to the core Emacs team (which is a substantial amount) being steeped in Emacs Lisp traditions is hardly an advantage. ELisp is a weaker language that has only managed to hold on because it is embedded in Emacs by default.
It is quite telling that Emacs is the only place that ELisp gets used as a style. Compare that to a lisp like Clojure where people love implementing Clojure in strange new places. Or Common Lisp which has more than 10 major implementations (and one in Emacs, naturally). Nobody chooses to use ELisp without serious prompting.
Someone writing bad ELisp doesn't say much about the quality of a package or how useful it will be.
I doubt it. Bad code takes longer to write, understand and is less maintainable. But it is rare that those are the issues that make or break an OSS project. Typically the maintainer's goals and motivation counts for much more.
And besides "good code" in ELisp is a bit of a funny one. Lexical scoping is a relative innovation.
> being steeped in Emacs Lisp traditions is hardly an advantage.
I used to think this, but sometimes this determines how deeply your package integrates into emacs.
The obvious example here being seamless tramp support.
IIRC this is demonstrated in this very interesting blog post[0] about debugging why opening a remote file is slow in the projectile package, likely didn't exist in the project.el alternative that is more steeped in those traditions.
As a user I shouldn't have to care/don't care about the code quality as long as it works. If lsp-mode provides more/better features there are very few reasons to not use it.
