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

["João Távora" <joaotavora@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2598 bytes --]

On Sun, Oct 2, 2022 at 4:52 PM Philip Kaludercic <philipk@posteo.net> wrote:

> > Those are all phrases in disguise.  Even "hl" is really two things.
>
> I guess so?                           What is the other thing?

I just meant "hl" is a itself made of "high" and "light", two unbreakable
signs.

> > One could have come up with a short phrase instead of Eglot, say
> > "emacs-very-bueno" or sth like that. That would probably be more
intuitive.
> > But also probably silly, and easy to miss the target.
> I am under the impression that we are talking past one another.  Yes, I
> agree that "emacs-very-bueno" and "Eglot" are equally opaque,

No, the first is not as opaque, it carries more meaning that it's something
that enhances Emacs (also tried to carry the meaning of "joke" in my
destitute sense of humor).

> but why is
> that important?  I am saying that it might be good to _at the very
> least_ add an alias for `eglot-ensure' consisting of only English words.

Such words would be "turn-on-eglot-if-its-not-on-yet".

> Also, do you have comments on the other suggestions form my previous
> message?

I don't think the conditions are there to turn Eglot on by default. Language
servers are a big variable.  They are lots and lots of code we have no
control
over and there are very many of them.  It's not like relying on "ls" or
"git".

Even if they were, I'm not convinced that's a good idea. *Maybe* Eglot
could
become more transparent (major modes could using it as a library to do
major-mody things) but never entirely invisible, I think. Meaning I think
the
user should never completely forget that there is a language server
connection currently tied to some major modes of a project, and managing
those buffers.

The command M-x eglot-list-connections doesn't exist yet, but I will add it
soon
for convenience and debugging purposes and to help reinforce this structure.

I think the popularity of `eglot-ensure`, while convenient, has somewhat
erased this sense of structure for some users, which sometimes makes users
have unrealistic expectations of how Eglot works, and hard to penetrate bug
reports. I recommend M-x eglot instead.

> > None of this makes any difference to the fact that Eglot is the best
> > name for referring to exactly what Eglot is.
>
> Tautologically yes, but this is too abstract.

Names, signs, are abstract indirections. What's in a name? That which
we call Eglot by any other name would just as many bugs I should
probably be focusing on.

(With apologies to W. Shakespeare)
João

[-- Attachment #2: Type: text/html, Size: 3240 bytes --]