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

[Tim Cross]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 09 Oct 2022 07:38:24 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>> 
>> > From: Richard Stallman <rms@gnu.org>
>> > Cc: emacs-devel@gnu.org
>> > Date: Sat, 08 Oct 2022 18:34:03 -0400
>> > 
>> >   > Yes, so take python-mode as an example.  It has both tree-sitter
>> >   > support and Eglot support.  How to use both? does it even make sense?
>> > 
>> > Do they do the same jobs?  Are they intersubstitutable, in principle?
>> 
>> Not clear yet (to me).  Dmitry says they are basically orthogonal in
>> the features they support.
>> 
>> One difficulty here is that Eglot exists for some years, so what it
>> does and how is pretty clear; by contrast, tree-sitter support in
>> Emacs is very young, and where it could potentially develop needs more
>> study, at least on my part.
>
> For example, at least up-front, it sounds like the LSP specification
> supports both fontifications and indentation.  Eglot, AFAICT, allows
> to request the language server to do the latter (via the eglot-format
> command), but doesn't support requesting information about token
> types, which could be used for fontification.
>
> 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").

To add to the complexity, 'best' will depend heavily on the LSP language
server being used. Some servers are more feature rich than others and
some are better implementations than others. For example, I changed the
language server I use with Javascript as I found a different one from
that being used by most LSP clients which was faster and handled
indentation 'better'. I can imagine there will be situations/languages
where tree-sitter does a better job than the currently existing LSP
servers for that language.

Whatever the default is, the user will need the easy ability to select
which functionality is provided by which package.