eglot vs lsp-mode

Hi, Over the years I have discovered that the sub is divided fairly evenly over `eglot` and `lsp-mode`. I was wondering, what makes users prefer one over the other? I am evaluating moving over from `lsp-mode`, now that `eglot` is shipped with emacs and it supports emacs-native features where possible. I mainly use python, julia, and web-devvy things like typescript, tsx, css, and html. Thanks! EDIT 21/10/2022 Thank you for all the information, advice and suggestions. Really appreciate it! <3

I'm in kind of the same boat. I've always used LSP-mode because it was recommended harder, but I only use it for powershell (so far) and it's kind of overkill. Will see if eglot suffices and switch to that pretty soon.

Whichever works :)

usually the right answer. The issue is with emacs packages by the time you understand how to use one of them it integrates enough into your workflow you become opposed to switching

I like eglot, but nothing against lsp-mode. I do think eglot is easier to get working quickly.

I tired lsp-mode and dap-mode and found the whole stack very buggy, eglot seems more stable and well written, and it’s going to be the default, so I guess ask yourself if there is a killer feature lsp-mode has that makes it worth the bugs. Since switching I’ve found that eglot does what I need.

Eglot feels a lot lightweight and less buggy that is why I use it

I am using lsp-mode for two reasons: 1. dap-mod 2. lsp-ui-doc dap-mode has no equivalent with eglot, and using pdb, gdb and the like does not feel as convenient (and productive) for me. I tried to setup eldoc and eldoc-box with eglot, but did not manage to get it to work to fetch documentation from the lsp-server (in this case pyright). Probably, I did something wrong but anyways. Stability and ease of use seems to be equal. consult-lsp serves my purposes also little better than consult-eglot.

Used lsp-mode for years, and it’s always been reliable. Whenever it was we got native json parsing in emacs head pushed things so that performance has been solid ever since. I’ve had good interactions with the primary maintainer, and I appreciate the lsp-ui features. In sum, it works well, it brings the snazzy if you want it, and it’s got helpful, friendly people behind it.

I use both. lsp-mode has more features so I use it when I can. But it slows down the entire instance on big codebases, and it is completely broken over tramp. For work I use a big codebase over tramp so there is only one viable option.

Eglot, being more light-weighted, has an edge in performance compared to LSP-mode. However, If you have a monster pc, then this should not be a problem. But on my computer, Apple M1 chip with 16g ram, I feel that eglot is a little but smoother than LSP-mode. Eglot does not support multiple LSP server attached to one buffer, this may be a killer feature for LSP-mode. Some files especially related to JS, HTML stuffs, multiple LSPs support are sometimes really useful. By the way, LSP-bridge is the fastest LSP client in emacs ( I mean significantly smoother for a mediocre PC), you can also take a look at that project if you are interested in trying alternative emacs LSP client. LSP-bridge’s UI is as fancy as LSP-mode (doesn’t integrate with builtin emacs features well in other sense)

Under Windows I never could Eglot convince to work with my JSON languageserver \`vscode-json-languageserver\` whereas lsp-mode worked out of the box, so I gave up. I am also using dap-mode to interact with dlv, the go debugger, and eglot has no counterpart.

So, I don't use lsp for much but to see function/type definitions. Take for example this simple rust code: ``` let mut file = File::create("does_not_exists.txt").unwrap_or_else(|why| { panic!("! {:?}", why); }); ``` with lsp-mode, if I put my cursor anywhere over `unwrap_or_else` I can see the whole function definition `pub fn unwrap_or_else<F>(self, op: F) -> T where F: FnOnce(E) -> T,`, also, if I put my cursor anywhere over `why` in the `panic!` macro call, I can also see it's definition `why: Error`. With Eglot the first case works only after going inside the function call (the cursor needs to be after the `()`, the second does not work at all. Similar things happen with C++ and that's why I don't use Eglot. Maybe I'm missing something in my config: ``` (after! eglot (setq eldoc-echo-area-use-multiline-p nil) (setq eglot-extend-to-xref t) (setq eglot-ignored-server-capabilities (quote (:documentFormattingProvider :documentRangeFormattingProvider))) (add-to-list 'eglot-server-programs `(rust-mode . ("rust-analyzer")) `(c-mode c++-mode . ("/usr/bin/clangd" "-j=4" "--malloc-trim" "--log=error" "--background-index" "--clang-tidy" "--cross-file-rename" "--completion-style=detailed" "--pch-storage=memory" "--header-insertion=never" "--header-insertion-decorators=0")))) ```

[removed]

Can mods start killing these threads? This question gets asked almost every week.

Apple M1 chip is already the "monster". There are only few high-end CPUs that provides better single-thread performance than M1, and emacs cannot use multithread anyway.

If the language server is a separate process (it is), then emacs+LSP does take advantage of multiple threads/processors. This is also true of lsp-bridge and eglot. The big performance differences come from the language servers, what they try to do/send to emacs, and what emacs tries to do with that data. The more complex that interaction, the more likely you are to see performance concerns. Since eglot is aimed at adding lsp information to existing emacs facilities, it tends towards lesser overhead/more performance, but it’s totally possible to make a grand-grinding-behemoth eglot setup and a stripped-down-greased-weasel lsp-mode setup, if one really wanted.

That was my experience. I happily used lsp, then switched to eglot as an experiment to see if I preferred it. There was considerably less config to get it up and running with the same functionality. They’re both awesome. I’ll stick with eglot because I don’t have a compelling reason to switch back, but if lsp got some brilliant new feature, I’d happily try it out.

Eglot has everything I need, and works more quickly. I found that I wasn't using the vast majority of lsp-mode's features. You should check a feature comparison to see if eglot has everything you need. If it does, you should use it.

Thanks. Yes, I do use multiple servers within a single buffer, especially during web development. Perhaps that will limit me to lsp-mode. Thank you for the information.