On Fri, Oct 7, 2022 at 6:56 PM Richard Stallman <
rms@gnu.org> wrote:
It sounds like the commands for using Semantic on a file may be very
different from the commands for using Eglot on that same file.
Is that right?
"Commands" is probably the wrong way to think about both Semantic/EDE and eglot (and lsp-mode, etc). The high-level idea in both cases is to enhance existing emacs facilities (including those that are enabled by default, those that are shipped with emacs but must be enabled by the user, and those that are packaged separately from the emacs core) by adding a more in-depth comprehension of the code the user is examining, modifying, writing, etc.
Many of these facilities (absent something like Semantic/EDE/eglot/lsp/etc) using heuristics, conventions, and regexp-based functionality to try to "understand" the code, and then use that understanding to help the programmer, for examples, with fontification, completion, pop-up documentation, additional navigation, and the like.
I believe that a big part of the difficulty of putting a concrete handle on "what does eglot (or semantic) do?" comes in here: many of the things that are enabled/enhanced are already present in emacs. For example, M-. runs xref-find-definitions to find the definition of the thing at point. Emacs has had this functionality for a long time, and there are several optional packages that enhance it, using TAGS, rtags, ag, or gnu global to *find* the reference, or using helm or ivy to access the references. Semantic and eglot (among others) add functionality that attempts to understand the code using the same mechanism that, for example, compilers use. (In Semantic's case, it implements compiler-like tokenizer/lexer/parser functionality in elisp; the Language Server Protocol (LSP) approach is instead to use an external tool, often built from the same parts as the compiler/interpreter, and communicate the "relevant information" over a channel to an editor).
In this sense, the "eglot commands" are just the ancillary machinery to make the enhancements happen "in the background" -- telling emacs to start using the facility, managing the connection and the external process, and, importantly, configuring that external machinery. That last is important because there is no "one true LSP server", even for a given language, so configuration is required. We can hope that this will settle out over time, but LSP (the protocol that the external tools use to provide editor-agnostic* information) is still developing, and people are discovering new ways to integrate a deeper understanding of code into editing (and reviewing, debugging, etc.) environments.
About Semantic: as has probably become clear by the time you read this, one of the particular issues of this precise moment in the conversation is that Semantic *does* parse the code in question, whereas eglot instead serves as a bridge between the external tools that parse (and more) the code and emacs' existing (and upcoming) features for editing (reviewing, etc.) code.
In a rough analogy, Semantic can be thought of as "let's replace rcs.el with something like CVS implemented mostly in elisp", while eglot (and its cousin lsp-mode) are much more like VC -- the glue between emacs and a variety of external tools for grokking C, _javascript_, Python, etc. VC abstracts over "version control". Gnus abstracts over "message systems". Eglot attempts to abstract over "understanding (computer) languages".
Hope that helps,
~Chad