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

[Tim Cross <theophilusx@gmail.com>]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > Sorry, no.  We will not start a dispute about renaming eglot, because
>   > that would delay its merge, and we don't have time for that luxury.
>   > We want eglot to be part of Emacs 29.
>
> We can make this decision in a week.
>
> Now, before including a package in Emacs, is the last good time
> to choose a helpful name.
>
> The policy that "We have left the issue so long that it is too late to
> choose a better name" leads predictably to accumulation of unhelpful
> names.  I speculate that this has been at work for decades, resulting
> in so many unhelpful package names now in Emacs.
>
>   > As for more basic arguments why not rename it: this package is not a
>   > new one, it is used by many people as a 3rd-party package.
>
> We can keep `eglot' as an alias for years or decades, or forever,
> if we choose a helpful name as the principal one.
>
> If there is no workable way to define alias names for packages, we
> should create one now.  The crucial thing is to have the various names
> in the _list of packages_, with the more helpful name preferred.
>
> The names of the package's entry points are less crucial.  We know how
> to give them aliases, but if they are numerous, that would be more
> nuisance than it's worth.  How many entry points does this package
> actually have?
>
> Given the existence of multiple packages for dealing with language
> servers, calling one of them just "language server" or "lsp" seems
> bad.  Rather, helpful names will show people (1) what job all these
> packages do and (2) that they are different ways to do it.
>
> Ideally, also, also what is special about each of these packags, if we
> can come up with good ways to do that.  It may not be practical.

While I can agree with the sentiment underlying this, I'm not sure I
agree with the practicality. The space of available meaningful names
which convey a meaningful description of what a module/library does
which are also not ridiculously long and are unique is actually quite
small. Naming things is difficult.

Given the most obvious and descriptive names are already taken, combined
with the fact eglot is already well known and scattered through
documentation and web pages all over the net, the pressure and tight
time line to get out Emacs 29 and the fact none of the suggested
alternative names are any more informative than eglot (many likely to
cause confusion with elisp and other elisp utilities), I think accept
this one and move on.

In reality, very few packages/modules actually provide any real meaning
based on just their name. It is too short to convey much. It is the
package description we rely on. In some ways, a distinctive name like
eglot is actually a positive - when I see it, I say "Hmm, I wonder what
that is?" and look at the description. Due to its distinctive name, I
will also remember that and what it does.

I also note that eglot is likely going to struggle to gain acceptance
over lsp-mode, which definitely has a much larger user base. Being
bundled in Emacs will certainly help. However, trying to change names
now will not help and runs the risk of further confusing the user base.

Besides, eglot aka Emacs Polyglot isn't a bad name and nothing better
has been proposed.