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: Yuan Fu
Subject: Re: Renaming eglot -- or at least add an alias?
Date: Tue, 11 Oct 2022 23:37:28 -0700


> On Oct 11, 2022, at 11:04 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> 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.

IMO in some sense, eglot and major mode sits at the same level, and tree-sitter 
a level lower. Consider this: take imenu as an example. Major mode sets 
imenu-create-index-function for imenu to function. A major mode now has two 
options available, one function uses tree-sitter and one don’t. If the user 
enables eglot, eglot sets menu-create-index-function to eglot-imenu, overriding 
major mode’s function. From this perspective, tree-sitter is just a mechanism a 
major mode could use, not unlike syntax-ppss, while eglot do things its own 
way, replacing parts of the major mode’s functionality with its own.

So it’s not really “two back-ends”, tree-sitter and eglot are different in 
fundamental ways.

Yuan




reply via email to

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