What I use Eglot for in GNU Emacs and what good it is

Recently, via Sacha Chua's Emacs News, I saw a Reddit question titled I've used emacs successfully for decades without using LSP or Eglot. Tell me what I'm missing. This started me thinking about what I use Eglot for and how I would answer this question, because in some ways I'm in this situation too. I don't really think of my programming with GNU Emacs as 'Eglot centered', although I have Eglot set up for (some) languages I program in.

My initial use for a LSP server in GNU Emacs was for 'as I type' autocompletion in Go, because at the time Go was moving from doing this through a program called gocode (also) to doing it through the then-new LSP stuff. These days, I use Eglot for a number of features (roughly in order of importance to me): language diagnostics, as I type autocompletion (in some languages), and jumping to definitions and uses of things, and I make some use of eldoc hints about the arguments of a function or method I'm writing a call to. I make a tiny little bit of use of code actions, and I don't use Eglot to format code at all; if I want my Go code formatted I'll explicitly invoke 'M-x gofmt', and other languages I don't trust the LSP server's code formatting (or, really, any 'standard' code formatting).

(Eglot can do more than this (cf), partly depending on the specific language and which LSP server you use. But the LSP servers I normally use with Eglot don't support things like 'inlay hints'.)

I say that I use Eglot for these features, but that's sort of a misnomer (for Eglot specifically). In reality I access a lot of these things through standard GNU Emacs features like xref's xref-find-definitions, standard autocompletion tooling, and Flycheck. These standard Emacs features draw their xref data, completion data, diagnostics, and so on from a collection of sources, and in the modern way Eglot is in large part a backend data provider to these standard features. You don't need Eglot to have most of these features, as shown by cases such as Emacs Lisp which don't have a LSP server, and I sometimes bypass Eglot even when it could provide data.

So another answer to why I use Eglot is that it's often the simplest way to source all of the data that I need to enable xref, diagnostics, completions, and so on for a language like Go or Python (or Rust). Part of this is because Eglot and LSP servers conveniently bundle everything together into one program and system so you don't have to find, install, and configure a bunch of separate bits. But also, for an increasing number of languages, running a LSP server is the only good way of getting this information. Sure, you can wrestle with things like Emacs tag tables and hope that you can generate good ones for your languages of choice, find standalone Flycheck or Flymake checkers, and so on. Or you could give in, run a LSP server, and have Eglot talk to it for you. Obviously, if you already have a working non-LSP setup that delivers the xref, diagnostics, and other stuff that you want, you don't need to use Eglot (or a LSP server), although you might get better xref and diagnostic information with a LSP server (or not).

(On Linux, you can even get LSP stuff for relatively straightforward old school C programs with a simple setup.)

Broadly, the more you want reliable syntactic and semantic information about code, the more you're going to need to lean on a LSP server for many languages (and then talk to it through Eglot, lsp-mode, or another Emacs LSP client). My understanding is that traditional regular expression based programming language Emacs modes provide relatively little reliable information here, but treesitter based modes can (potentially) do more because they have a deeper syntactic and semi-semantic understanding.

(I don't really know what sort of xref and so on based things are possible without Eglot but with a treesitter language mode, because I haven't looked into that much. On a quick check it seems it needs some setup work in GNU Emacs 31, perhaps because the ts modes aren't known to everything yet.)

If I was pitching Eglot to someone writing code with a traditional, non-LSP Emacs setup, the two features I would focus on are diagnostics and xref-based code navigation (with a bit of mention of eldoc hints). These features basically work without any special Eglot or other configuration and are already standard Emacs things that people may already be using (unlike basic Emacs symbol completion, which works in Eglot without configuration but I think mostly doesn't work in stock non-Eglot setups).

PS: One obvious place where semantic knowledge is important is things like reliably renaming variables or functions across your code. On the other hand, maybe we'll start doing those outside our editors. For various reasons I don't do this often and when I do it, I tend to reflexively do it by hand rather than asking Eglot to rename things.

There are changes that would be really handy to do through Eglot, but as far as I know very few LSP servers support things like 'add a new argument to this function and make the initial value of it at all call sites be X', or 'remove this function argument from the function definition and all call sites'. I think in practice people do these sort of changes by changing the function itself then using error diagnostics from the LSP server to find and fix all of the new complaints.