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: Tim Cross
Subject: Re: Renaming eglot -- or at least add an alias?
Date: Wed, 12 Oct 2022 20:24:06 +1100
User-agent: mu4e 1.9.0; emacs 29.0.50

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

This all seems to get very confusing/complicated quite fast.

In case it helps, as a user, for most of the languages I work in, here
is what I would want (assuming eglot/tree-sitter support available for
each language.

- Tree-sitter for font lock and indentation. I don't think eglot will be
  fast enough given json parsing and process comms etc.
  
- eglot for linting, xref, completion, doc lookup, code actions etc.
  Most of the time, I want this on a project rather than a file
  basis. Also, I want something which is consistent with co-workers who
  use other editors, but the same language server.

So for me, I want to be able to specify for xxx-mode, use tree-sitter
for font locking and indentation and eglot for everything else. Being
able to easily set that in myh init will be what I am looking for. 



reply via email to

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