Eglot is merged into emacs git master

Sounds like a big deal. I have been using lsp mode for some time. I dont have any preference at this moment. If something works i will be happy. Is elgot better than lsp mode?

What does this mean

Define your criteria, when we may (!) answer if it is better. As usual, it's better in some areas, less in others. Is notmuch, mu4e, wanderlust or gnus better? Is erc, circe or rcirc better? If there would be dome universally true answer yo these questions, when only one of these would exist.

[Eglot](https://github.com/joaotavora/eglot), an [LSP client](https://langserver.org/) for Emacs, will be shipped with Emacs. One could already install it as a package, but now it will be installed by default with the rest of Emacs. One can still use other clients if they so wish.

In my experience, eglot is more reliable and performant than lsp-mode, and leans more on the existing Emacs ecosystem: for example, eglot encourages you to use the builtin `xref-find-definitions` for jump-to-definition, whereas lsp-mode provides its own `lsp-find-definition` built atop xref's core. Eglot's UI, however, is less featureful, and it doesn't integrate with the debugger provided by dap-mode. (edit: clarified my meaning re. eglot/lsp philosophy)

This is huge, congrats to everyone involved. Eglot is a fantastic piece of software

lsp-mode uses xref too.

Ah, I see it uses xref under the covers. I've edited my comment to be more precise about my meaning. Thanks for letting me know.

Yay! I recently switched to Eglot cuz I heard this might be happening. I think it fits better than LSP-mode to ship as default. Not because its better than LSP-mode, but because its more minimal

More minimal!

Felt that way to me at least. Am I wrong? It doesn't even auto start servers by default, right?

Great news. This together with the treesitter work should lead ti much deeper language support across time.

eglot is more idiomatic elisp, while lsp-mode uses libraries like dash and s.

It does.

Great, use it for a long time and pretty happy with it. Although it would be prudent to rename it to lsp.

Oh

Lsp mode gives more features that you would expect from IDE’s

Minimally moreso.

Can’t rename it to lsp cuz there’s already an lsp package lol

This is great. Have eglot installed but haven't actively used it. I've been using tide-mode because it just worked with minimal effort. Probably gonna try again this weekend.

This is great. I wish I could use eglot in its current state, but it does not support running multiple servers in a single buffer. As a TS/JS frontend developer, I love the ability to run both the eslint server and the ts-ls server. The workaround is to run flymake with eslint directly instead of the language server, but I really like the code actions that the eslint server provides. There is talk (and maybe an abandoned implementation) of a language server proxy that can be a stand-in for a language server and forward requests to multiple language servers. That would be a good solution. lsp-mode just handles it directly though.

I like eglot, it's minimal, performent and integrates with built-in Emacs features better. But LSP client might be something you actually want to be a maximalist. For quite a few servers lsp-mode gets you out of the box support or more features, whereas imo eglot is rougher around the edges, though perhaps now it will get more eyeballs and get better. I am glad that both exists, however if all you care about is something working and lsp-mode works well enough, I doubt eglot will be even better (as of this moment) in more cases than not. However you can have both installed and it will take minutes at best to try it out so just give it a go.

Ya single server support and no option for dap -more is enough for me to stay with lsp-mode for now.

It uses it but it doesn't integrate with it, which means it doesn't play well with anything else that also wants to hook into crossreferencing.

I have mixed feelings about this because it means that if LSP goes away for some other standard, the Emacs maintainers will be stuck with it. I doubt that's going to happen, and the devs took it into account, but still... How's the configuration part of this? If you can just turn it on and it works (assuming you have a language server), I think that would do great things for Emacs adoption.

I don't think that's true. Not by default. Unless you mean that it starts the server when you do `M-x eglot`, because it does do that.

I have a pretty vanilla lsp-mode setup. In a source buffer I hit `M-.` or `M-?` to call `xref-find-definition/references` and I get the results in the `*xref*` buffer. lsp-mode handles it via `lsp--xref-backend` which is in `xref-backend-functions`. That seems like the normal xref way to do it. Or do you have something else in mind?

I can't give you an objective answer, but I can give you my personal experience: For me, I found eglot needed some extra configuration to get working with the lesser known/tested LSP servers that I need for my work, which took me a hell of a while to figure out because I suck at elisp and misread the docs. Once set up though, I find it works great - very reliable and simple. One caveat I had was with TypeScript - eglot can't run more than one LSP server at the same time, so you have to use a separate package for ESLint if you use it along tsserver. But I think that's a perfectly fine solution and it honestly works better than lsp-mode, [which required me to install a separate package just to get errors to show up properly.](https://github.com/emacs-lsp/lsp-mode/issues/2808)

Yay! But I want eglot support call-hierarchy.

It is still incorrect. lsp-mode provides also xref-* methods. We have the lsp-* one because LSP cannot be used to properly implement the xref interface and xref cannot be used to expose all LSP protocol functionality.

Let's rename Arizona to Nevada.

Perhaps “elsp”? … no, wait, don’t do that!

ah, a fellow frontend dev. What is you experience with performance? For me, lsp-mode (and eglot) with ts-ls is horribly slow, and I cannot for the sake of it get it to run smoothly. Is it me or is this a generel problem?

Performance is pretty good, mostly, depending on project size. I do not use lsp-ui at all so my usage of it is pretty Emacs-y.

I wonder since Eglot is becoming the standard, If it makes sense to rebase your work on Eglot?

I do not understand how you imagine LSP going away. LSP is a protocol. Typically, an LSP server runs on the user's machine, not as some third party provided web service. Even if some "better" protocol shows up and gains greater popularity than LSP, LSP will continue to exist. And just as surely, there will continue to be emacs user who, for whatever reason, continue to use LSP. So, of course emacs will continue to support LSP, as well as any worthy new comer(s). As an existence proof I offer emacs' support, via its VC framework, of version control systems all the way back to SCCS. Not abandoning its users is a fundamental value within the emacs community.

Not sure what rebasing means here. And being in core does not make one package the standard - projectile vs project.el, viper vs evil-mode, flymake vs flycheck. IMHO in the end the package quality/user preference is what matters the most.

I don't disagree with anything you just said. The point is that it would be easier just to stick it in ELPA as the "recommended option". Merging it into the core is an acknowledgement that Elgot is a core component of the Emacs experience. While I'm looking forward to using it, I'm surprised that the Emacs maintainers thought the same thing, and thought they would be more conservative.

> thought they would be more conservative The LSP exists since 2016. How more conservative can we be?

Maybe? In that world, Tetris has been a core component of emacs for longer than JavaScript has existed.

Sure, but it's still more code to maintain. I think that's the concern.

What’s the story on using typescript and eslint with eglot? Lsp-mode has good support for running two language servers at the same time. That’s important in React development because several crucial lsp powered refactorings are powered by the eslint language server. You need eslint for more than just diagnostics. With lsp-mode I can run both language servers, without having to commit any config changes to the typescript project(s). That’s nice because I’m the only emacs dev on most of the typescript projects I work on and wouldn’t want to explain why I’m committing config changes just for me, plus I work on a lot of projects. With lsp-mode it just works using both servers. The relative minimalism of eglot does appeal to me. If I could run both language servers without touching my typescript project configs I’d give eglot a whirl.