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

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 06 Oct 2022 18:09:12 -0400
> 
>   > Seeing that eglot would still keep it's original name, there is little
>   > to no reason to make up a name on the spot, and stop or hinder Eli
>   > from going forward working on the next release.
> 
> If we include the package in the Emacs 29 release, that will call for
> mentioning it in many places in documentation for users -- the places
> that document the features it enhances.

"Many places" is an exaggeration, IMO.  Eglot will come with its own
separate manual, will be briefly mentioned in the Emacs manual, and
will be called out in NEWS.  That's all I see at the moment.

> Even if its own source code still carries the name "Eglot", those
> improvements in documenation should carry the clearer name.
> And a few places in the code should use the other name.

The documentation mentioned above will explain what Eglot is and why
that is its name (I'm working on the Eglot manual as we speak, so I
know that's what the manual will do).  But the name of the package is
Eglot since 2017, when it appeared and Emacs users started using it,
so it would be incorrect and un-clever for us to change its name 6
years after its appearance.  We can (and will) make it easier for
users to understand what its features do, by labeling the menus and
describing in the doc strings and help-echo strings what the commands
and variables really do and what effect they have on Emacs.  If
needed, we can also provide aliases or front-ends for Eglot commands
and variables whose names don't mention Eglot, but are related to the
command's or variable's real effect.  For example, the command to
start the language server and connect to it could have a name to that
effect, or it could have a name related to the fact that it turns on
language-server support.

Please also keep in mind that many (perhaps even most, I didn't count
yet) of Eglot's features are not explicitly invoked via the likes of
"M-x eglot-SOMETHING".  Instead, you enable Eglot in a buffer or for a
project, and then features we already have in Emacs, like M-. or
xref-find-references, or completion-at-point, or eldoc documentation
and function signature hints, or flymake diagnostics -- these and
other features are _enhanced_ by the information coming from the
language server.  Eglot works in the background, feeding these
features with the language-server derived information, and is
otherwise almost completely invisible to the user.  So we are arguing
about the name of something that is barely visible on the user level.

> So we have a reason to finish this now.

Documentation and menu labels are something that can be finalized
after the release branch is cut, as it is routine maintenance job that
is not of critical importance for the code stability.  So I see no
need to rush with that.  We should have this discussion later, after
Eglot is in core, people have read the documentation and tried to use
Eglot in Real Life, and have much better understanding what it is and
what it does (and also what it isn't and doesn't).