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: Wed, 12 Oct 2022 16:05:50 -0700


> On Oct 12, 2022, at 12:15 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Tue, 11 Oct 2022 23:37:28 -0700
>> Cc: Richard Stallman <rms@gnu.org>,
>> emacs-devel@gnu.org
>> 
>>> 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.
> 
> My vision of the relation is different from yours.  Major mode sets
> imenu-create-index-function to some code that can either use
> tree-sitter or some other way of detecting the symbols for the index.
> That other way includes Eglot.  The fact that Eglot overrides the
> mode's setting is just an implementation detail.
> 
> And none of that matters for the user, btw.  Users don't care much
> about implementation, they only care about the possible ways of
> getting the functionality, and in this case there are 3 such ways.

Ah, that makes sense. Then maybe we want major modes to have more say on what 
function uses eglot and what not, because eglot simply “takes over” right now. 
But I don’t have anything insightful to say about that.

Yuan


reply via email to

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