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

[Dmitry Gutov]

On 09.10.2022 07:57, Eli Zaretskii wrote:
> > 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.

LSP syntax highlighting is a new-ish thing, and apparently isn't 
supported by Eglot. Further, passing the highlighting information over 
the wire is bound to be slower than the in-process integration offered 
by TreeSitter.

Indentation - maybe, I'd have to check how well it works first. The 
indentation code we have already seems to be good for the majority of 
languages, and having it in Elisp makes it more easily hackable and 
customizable.

TreeSitter indentation logic will not be entirely in Elisp, but almost 
as hackable nevertheless.

> 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'd recommend keeping the divide where I described it, but then keep an 
eye out for whether one of the options makes a noticeably better job 
somewhere at the other's turf. Maybe after Emacs 29.