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

[Tim Cross]

Philip Kaludercic <philipk@posteo.net> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>> [[[ whether defending the US Constitution against all enemies,     ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>>   > >> Can anyone suggest a way to describe the job that Eglot does, NOT
>>   > >> using technical jargon, or implementation details such as "LSP"?
>>
>>   > Some ideas of the top of my head:
>>
>>   > - ide-mode
>>   > - integrated-development-mode
>>   > - {smart,intelligent,clever}-mode
>>   > - programming-mode
>>   > - syntax-mode
>>
>> You've tried to resent descriptions which are short enough that they
>> might serve as command names.  Unfortunately, that shortness makes
>> them less than helpful for explaining the job that Eglot does.
>
> That is kind of the issue, isn't it?  Eglot (or LSP in general) doesn't
> add any new features, it just improves the accuracy of what already is
> built-in.
>

I think your correct that eglot doesn't bring any new features. What we
are really talking about here is a new architecture where, in an ideal
world, each language would provide its own language server that all
editors would leverage off via a client like elgot. There would be no
need for individual editors to re-invent functionality such as linting,
code snippets or editor specific language parsing etc. As such, it
offers the potential for simpler and more efficient editors that have to
worry less about keeping up with the evolution of a specific language.

However, it may not be accurate to argue that eglot (and LSP generally)
provides improvement or more accurate functionality. There are cases
where the LSP based solution may not be as good as a very sophisticated
mode for a specific language. For example, while I find an LSP based
solution really good when I'm working on Javascript, I still find cider
mode better when working with Clojure. LIkewise, not all LSP servers are
equal. Some are better and/or more sophisticated than others. 

This new architecture is not just beneficial for editor
developers/maintainers. Users benefit because of a simpler configuration
experience. Prior to LSP and an Emacs lsp client, I had to configure a
number of different emacs packages in order to get a useful Javascript
development environment. Now, all I have to do is install one of the JS
LSP servers and eglot and the job is done.

Trying to find a new name which reflects what eglot does is problematic
because what it does is the same as what many other packages do. What is
different is the way (architecture) it sues to achieve this. However,
that doesn't really help either - if we use a name which is somehow
derived from eglot's role as an lsp client, we cause confusion because
there is more than one lsp client and when people try to communicate
around this, things get confused between the package called lsp client
and the different 'things' which are lsp clients. Likewise, when
searching for help or past messages/articles, you get too much 'noise'
because the name your using is too similar to other uses or
functionality.

The whole idea of names which reflect the role or purpose of a package
is flawed. It results in generic names which make searching for
information specific to that package much harder. In many cases, such
generic names tend to provide little real value anyway.

On the other hand, if you have a unique name which doesn't tell you
anything about what a package does, what are you likely to do - look at
it more closely and likely read the package description. Not only can
you provide a unique distinct name which makes communication and
searching easier, you may actually peak interest more than a likely
limited descriptive name which makes something seem irrelevant or more
limiting than it needs to be.