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

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Tue, 11 Oct 2022 17:15:28 -0400
> 
>   > So, at least in principle, the functionalities based on these two
>   > could overlap.  If that is indeed so, we'd need to decide whether we
>   > support the overlapping functionalities or use each one of these
>   > packages for capabilities that are disjoint, whereby each
>   > functionality is supported by the package that does it best (for some
>   > value of "best").
> 
> I suggest that we define the principal user interface to enable or
> disable the user-level features, not the implementation mechanisms.
> 
> We could have a way to enable or disable multiple user-level features
> at once, and/or ways to enable or disable specific user-level features
> one by one.  But they should not be tied to implementation mechanisms.
> 
> Of course, we can offer the user additional control over which
> implementation mechanisms to use for this or that.  If it is not too
> hard or worth the trouble, why not?  But such fine control should be
> for those who want to be wizards.
> 
> People who just want some smarter editing features should not need to
> know what is implemented by Eglot, what is implemented by Tree-sitter,
> and what is implemented in some other way.

This discussion is primarily about our design and implementation
decisions: whether some features need to have more than one "back-end"
or just one, decided by us.  AFAIU, we haven't made the final
decisions yet.  Whether and how users will control that comes later.
If we decide that each feature will have only one "back-end", the part
of selecting a "back-end" is automatically resolved to a non-issue.

Regardless of the Tree-sitter vs Eglot issue, we already have this
kind of problem with tree-sitter alone, in modes that can perform
fontification based either on the font-lock-keywords machinery or
using tree-sitter.  We'd probably need to give users control which one
to choose, even if tree-sitter is installed and available, at least in
the short run.

> A few weeks ago, I expected we would want to have an Eglot manual, but
> now I think that is the wrong way to organize our documentation.  We
> should organize it by functionalities, each functionality described in
> its proper place in the Emacs manual.

The Emacs manual will shortly mention Eglot where relevant, and point
to the Eglot manual.  Description of the functionalities which Eglot
enhances don't need to be modified, not as a rule.  But we cannot
avoid having an Eglot manual, because there's Eglot-specific stuff for
which the Emacs manual is not the right place.  We have a separate
Tramp manual for the same basic reasons, although Tramp is well
integrated into Emacs and editing remote files is largely transparent
(except for the fact that various commands could be slower with remote
files).  There's also the non-negligible consideration of the sheer
volume of the Emacs manual.

With time and experience, and maybe if we add other "back-ends" with
similar functionalities, we could rearrange the manuals and the stuff
each one of them says.  But I see no reason for making such decisions
now.  Our manuals are not Holy Scripture, they can be changed as we
see fit any time we find it necessary.

Eglot has a significant community of users, and they are already used
to its current command and variable names; we are not starting the
naming game from scratch.  So any "abstraction" of the UI and the
names we'd like to do will have to be slow and with
backward-compatible aliases anyway.