Eglot: the Emacs LSP client that now ships inside Emacs

What problem Eglot solves, and who it is for

Emacs has always been able to run a compiler and parse its output, but that gives you diagnostics after the fact. Language servers give you completion, diagnostics, definitions and references while you type, and each server speaks a JSON-RPC protocol over stdio. Eglot is the client side of that conversation. The README describes it as the Emacs LSP client that stays out of your way, and the design follows that claim: there is no new UI to learn, no separate project model, and no configuration file to maintain before you see anything work.

The intended user is an Emacs user who already has a language server binary installed for their language and wants Emacs to talk to it. The README lists servers for Ada, Bash, C and C++, C#, Clojure, CMake, CSS, Dart, Dockerfile, Elixir, Elm, Erlang, Fortran, Futhark, Go, Godot, HTML, Haskell, JSON, Java, JavaScript, Kotlin, Lua, Markdown, Mint, Nix, OCaml, Perl, PHP, PureScript, Python, R, Racket, Ruby, Rust, Scala, TeX and LaTeX, VimScript, YAML and Zig. That is a wide net, and it is the reason the first command is usually enough.

It is a poor fit for someone who wants a single application that bundles the editor, the server manager and the UI. Eglot assumes you bring the server.

How Eglot talks to a language server

The mechanism is a long-lived subprocess per buffer. When you invoke M-x eglot, the command inspects the buffer's major mode and looks up a matching entry in the eglot-server-programs variable. If it finds one, it starts that program as a child process, performs the LSP initialize handshake over stdin and stdout, and from then on routes editor requests and server notifications between Emacs and the server.

The README points to sibling packages that Eglot integrates with rather than reimplementing: Flymake for on-the-fly diagnostics, ElDoc for documentation at point, Xref for definitions and references, and Project for project roots. That split matters when you are debugging. If completion behaves oddly, the problem may be in completion-at-point or company-mode rather than in the protocol layer. The README notes that Eglot works with the built-in completion-at-point, usually bound to C-M-i, as well as with company-mode, and that snippet completion requires yasnippet to be enabled before Eglot connects to the server. Order of initialization is therefore not cosmetic.

There is no daemon and no shared server pool described in the README. Each connection is started by the command and lives with the buffer, which keeps the model simple and makes the failure mode equally simple: if the server process dies, that buffer loses its features.

Installing Eglot from GNU ELPA and running it once

The stable route documented in the README is GNU ELPA, and it requires Emacs 26.3 or newer. The README gives the exact command: type M-x package-install RET eglot RET. After that, open any source file and run M-x eglot. The README states that this guesses the LSP program to start for the language you are using, and otherwise prompts you to enter one.

M-x package-install RET eglot RET
M-x eglot

If you want the version that tracks Emacs master, the README documents adding GNU-Devel ELPA to your package archives first. This snippet is copied from the README and is Emacs Lisp, evaluated in your init file.

(add-to-list 'package-archives '("gnu-devel" . "https://elpa.gnu.org/devel/"))

With that archive configured, the README says M-x package-install or M-x package-update installs an ELPA package from the latest upstream, and that M-x eglot-upgrade-eglot should also work if Eglot is already installed. What you should see after a successful start is the server process attached to the buffer and completion and diagnostics arriving from it. If nothing happens, the likely cause is that no server binary is on your PATH, at which point M-x eglot prompts for the program to run.

For a language outside the built-in list, the README says the full list lives in the eglot-server-programs variable and that you can easily add your own servers there, with the manual covering the details.

The repository is a mirror, not the development upstream

This is the part that changes how you should treat the project. The README states plainly that Eglot is in Emacs core since Emacs 29 and that this repository is not the development upstream anymore. Pull requests will not be merged, though they can still be used to show ideas for patches. The eglot.el file here is periodically updated to mirror the Emacs upstream, and eglot-tests.el is likewise updated periodically and can be used to rehearse and validate patches through the GitHub CI infrastructure.

So the code you read on GitHub is a copy. Contributions go by email to [email protected], and the README recommends compiling Emacs from a Git repository to experiment with changes. Bug reports can be filed with M-x report-emacs-bug, and the README asks you to follow the Eglot-specific bug-reporting instructions. The practical consequence is that a GitHub issue or pull request is not the path to a fix. If you file one there, expect it to be redirected.

The last push to this repository was on 2026-08-17, and the repository is not archived. That cadence is consistent with a mirror that is refreshed periodically rather than a project developed here.

Where Eglot is the wrong tool

Eglot implements the standard protocol. The README points to eglot-x for non-standard protocol extensions, which tells you that anything a server offers outside the specification is not covered by the core package. If your workflow depends on a vendor extension, you are adding a second package and accepting its maintenance.

Multi-server support is a second boundary. The README directs readers to the manual's multi-server section and to Rassumfrassum for multi-server support, rather than describing it as built in. If you routinely want two servers attached to one buffer, for example a language server plus a linter speaking LSP, this is a configuration you assemble rather than one you get.

A third limit is the process model. Eglot starts a server per buffer and has no documented pooling or restart policy in the README. On a large project with many buffers, that means many server processes, and the memory cost belongs to the servers, not to Eglot. The README does not document rollback or a downgrade path for a bad server or a bad package update, so pinning behavior is something you arrange through your package archive choice rather than through a documented switch.

Eglot compared with lsp-mode, and what the comparison actually turns on

The most common alternative is lsp-mode, and the honest difference is scope. Eglot's stated design goal is to stay out of your way: it wires a server into existing Emacs facilities such as Flymake, ElDoc, Xref and Project, and the README presents that integration as the reason the package moved into core, where it can be worked on in tandem with those packages. lsp-mode is a larger framework with its own UI layers and integrations, which is more surface to configure and more surface to learn.

Neither approach is strictly better. If you want a thin adapter that reuses the Emacs you already configured, Eglot's model matches that. If you want the framework's own UI and its broader set of integrations, that is a different product decision, and the README does not argue against it. The useful question is not which is faster in the abstract but which one you can debug when a server misbehaves, because in both cases the server is doing the analysis.

A second comparison people raise is against tree-sitter based tooling. Those solve a different problem: parsing for syntax highlighting and structural editing without a server process. Eglot's features come from a server that understands the language semantically. The two can coexist in one configuration, and choosing between them is choosing between structural parsing and protocol-driven analysis, not between two implementations of the same thing.

Licence and the cost of staying current

Eglot is GPL-3.0. If you install it from GNU ELPA or use the copy that ships with Emacs 29 and later, you are using it under that licence. This is not legal advice, but the practical point for most users is that running Eglot in Emacs carries no additional obligation beyond the licence of the editor itself. Distributing a modified eglot.el is a different matter and is where the copyleft terms start to matter.

The upgrade story is where the mirror arrangement has a cost. On GNU ELPA you get stable releases; on GNU-Devel ELPA you get the same version as Emacs master, which the README states explicitly. That is convenient and also means you are tracking development code. The README documents M-x eglot-upgrade-eglot for updating an installed copy, which is the closest thing to an upgrade command in the README.

For contributors, the cost is steeper than for users. Patches go to a mailing list, copyright assignment may be requested, and the README recommends building Emacs from source to test changes. That is a real barrier compared with opening a pull request, and the README is upfront that it is the intended process.

Editorial conclusion

Adopt Eglot if you want LSP inside Emacs without a framework: install it from GNU ELPA with M-x package-install RET eglot RET, open a file, and run M-x eglot. Skip it if you need a feature outside the standard protocol, since the README points to eglot-x and Rassumfrassum for extensions and multi-server setups rather than promising them in core. Before committing, verify two things: that your Emacs is 26.3 or newer if you install from GNU ELPA, and that the language server you need appears in eglot-server-programs, because an unlisted server means you add it yourself.

Frequently asked questions

Official sources

1. Issues
2. joaotavora/eglot on GitHub
3. License: GPL-3.0
4. README