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

[Philip Kaludercic]

João Távora <joaotavora@gmail.com> writes:

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

I see, but then again those are the two syllables that constitute the
word, so it isn't totally arbitrary.

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

Interestingly enough it only does that if you are familiar with the
non-English word "bueno".  That being said, I get your point but am not
convinced.

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

I am getting more and more confused.  What does this have to do with
what I said?

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

I am curious to hear why you think this should be.  Is it not preferable
to make use of the tools the environment is providing instead of falling
back on approximate heuristics like grepping for where a variable
occurred or using TAGS-files for definitions and completion?

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

That will be nice to have.

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

To be fair, I do that too, and this is why I wanted to prose adding an
alias to make it easier to remember the command.  We enthusiasts often
overestimate the readiness of more casual users when it comes to
remembering commands, bindings, packages, etc.  If possible, and I still
think it is, we should try to help.