Re: Renaming eglot -- or at least add an alias?

[chad <yandros@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3504 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4114 bytes --]