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

[Yilkal Argaw]

> Personally, I would just stick with eglot as I think this whole argument
> regarding the need for package names to describe their functionality is
> misguided. Great if you can do it, but should not be a necessity.

I agree. There is also the issue of the already established user base
and documentation (including unofficial documentation that accumulated
over the life cycle of the package by users documenting how they use
it, how people should use, solutions to questions and issues etc). I
don't think it is possible to backtrack and change them all to refer
to a new name.

“Who knows a man's name, holds that man's life in his keeping”
― Ursula K. Le Guin, A Wizard of Earthsea

with regards
Yilkal A.

On Sun, Oct 2, 2022 at 5:28 AM Tim Cross <theophilusx@gmail.com> wrote:
>
>
> Richard Stallman <rms@gnu.org> writes:
>
> >
> > Can anyone suggest a way to describe the job that Eglot does, NOT
> > using technical jargon, or implementation details such as "LSP"?
>
> Isn't that the crux of the issue - it seems nobody has any suggestion
> any better than eglot. Quite a few of the suggestion are worse.
>
> One thing you could do is just call the package eglot-lsp, which might
> give you the additional name info you seem to desire. The package
> namespace could remain eglot-*, so perhaps would not have the overhead
> and delay to release of Emacs 29 which a full rename would cause.
>
> Personally, I would just stick with eglot as I think this whole argument
> regarding the need for package names to describe their functionality is
> misguided. Great if you can do it, but should not be a necessity.
>
> In general, it seems only very simple and single purpose packages lend
> themselves to clear descriptive names. For example, tempo, skeleton and
> flycheck. Few packages which perform multiple functions seem to have the
> sort of descriptive name you are after. The name closest to function I
> can think of for eglot would be lsp-client, but that is too close to
> lsp-mode and in general, too close to 'lisp' and 'elisp'. Using the full
> name i.e. language-server-protocol-client is cumbersome, we be shortened
> in actual use and will likely result in confusion with lsp-mode.
>
> A good name is the one which you can easily remember and
> communicate. Once you are told what eglot does, you will remember
> it. You don't need its function to be in the name.
>
> > Would the word "parse" be good?  "Code-analyze"?
> > I never used Eglot so I don't know what it does.
>
> No, none of those words/terms are appropriate. Eglot is essentially just
> a client for servers which implement the language server protocol. It
> simply takes the data provided by those servers and uses it to annotate
> your code using flymake. It is just the glue between a language server
> and flymake - we could call it language-glue or ide-glue! Neither are
> jargon or too technical (I doubt IDE is considered jargon or technical
> these days).
>
> If you are going to insist on a new name, I would suggest you also need
> to understand what eglot is and what the language server protocol
> architecture is about. Without these key elements, you are unlikely to
> be in a position to judge the suitability of the name.
>
> See for example
>
> https://whatacold.io/blog/2022-01-22-emacs-eglot-lsp/
> https://langserver.org/
>