emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: Re: Renaming eglot -- or at least add an alias?
Date: Sun, 09 Oct 2022 16:30:11 +0300

> Date: Sun, 9 Oct 2022 15:44:19 +0300
> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> >> 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.

I'm not trying to make an argument, just point out that the jury is
still out about these issues, and we need at some point make our
minds.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]