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

[Philip Kaludercic <philipk@posteo.net>]

Tim Cross <theophilusx@gmail.com> writes:

>> Honestly, I think that commands like eglot-rename should either be
>> aliased or wrapped by some other prefix-less command
>> (e.g. "rename-symbol").  User options are more tricky, that is true.
>
> I doubt that would work well. The functionality 'rename symbol' is a
> common term and one which many language modes also implement. Why would
> eglot (or whatever it ends up being called) be able to 'own' that name? 

Because Elgot is being merged into the core?  Also, as I say this
doesn't have to be a direct alias.  I can imagine an xref-like backend
system where Elgot is just one of the implementations.

>> A more radical idea, but that might be something for Emacs 30+ could be
>> to just enable Elgot by default when everything necessary for using it
>> is available.  Then new users wouldn't have to bother with finding out
>> what the right packages, user options, etc. are and could just use it
>> OOTB.  That would be assuming that anyone with an LSP server installed
>> is actually interested in using it.
>>
>
> I think this misses the main strength of Emacs.
>
> Emacs is largely about being able to craft the experience you want. It
> isn't meant to be a clone of all other editors where everything comes
> 'out of the box' based on what some other people believe is the right
> setup. 

This is a cliche, and an inaccurate one on top of that.  Emacs isn't a
blank slate where you pick and choose everything.  Many things are
"forced" upon users: Why does Xref use TAGS-files by default?  Why is
font-locking enabled by default?  Why is anything bound at all?  Why are
any packages even bundled with Emacs in the first place?

What you say is a common impression because a lot of "modern"
functionality is missing OOTB, like the stuff that Elgot provides.  The
reason why packages are bundled is because Emacs ought to be useful.
Elgot does a good job at "super-charging" xref, imenu, capf, etc. so
UI-wise nothing is changed, just improved.

That being said, there are at least two points that should be considered
before 29.1 is released:

- The rebinding of `display-local-help'.  I don't get why this is done.
- The custom mode-line modification instead of eglot being just another
  minor mode item.

>        Besides, there is no such thing as 'a language server' - there
> are different servers for different languages and it is quite likely
> there will be multiple different language servers for a single language
> (already the case with some languages like javascript).

Ok, but that is already something that Elgot handles with
`eglot-server-programs', right?

> I also think this boat has sailed. We already have sufficient numbers of
> packages which for whatever reason, don't have 'intuitive' names. In
> fact, it is probably impossible to achieve such a thing given
> differences in languages, cultures, technical backgrounds etc. We don't
> even seem to be consistent here. We have been asked to come up with a
> new name which is intuitive, but does not involve jargon or require
> inherent technical knowledge. How is this going wiht respect to other
> packages, for example, the very interesting tree-sitter? What is that
> going to be called? The term tree-sitter is very jargon and technical
> based. Anyone not familiar with lisp is unlikely to know what that is.

Even if this might be the case (Lars indicated that it is so), I at
least want to have made a serious effort at trying to find an
alternative.

> The point is, we already have to rely on package description and not
> package name for meaning. This is unlikely to change. If someone was
> able to suggest a good name, I'm sure it would be adopted, but nobody
> has. 

Not sure about that, the main reason I think was that due to the
approaching release of Emacs 29.1 we don't have the time to properly
rename the package.  Which is why I have just been asking for an alias.
Some name where if someone asks me in person how to enable
auto-completion, the next question isn't "How do I spell that?" or "What
was that name again?".

It seems to me that most people in support of "Eglot" as a name reject
everything else because it isn't perfect or an exact description.  As if
there is only a hypothetical, ideal name and everything else is equally
inadequate, whether "elgot", "eglot", "ide-mode", "foobarbaz" or
"chair".

>      So gar, eglot seems to be as good as any other suggestion IMO,
> especially at this 11th hour when hard working dedicated maintainers are
> trying hard to get this package merged into emacs and release Eamcs
> 29. I also suspect, given all the information and documentation out
> there about eglot, changing branding now would just be detrimental to
> both that package and Emacs.
>
> At the end of the day, I think the name given to a package should be up
> to the developer(s) of that package. We can provide guidelines and
> recommendations, but the final decision should rest with those who
> actually do all the work.

In general yes, when an important feature like this is being merged into
the core, then I think it is absolutely reasonable to question something
like this.