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

[Tim Cross]

Philip Kaludercic <philipk@posteo.net> writes:

> João Távora <joaotavora@gmail.com> writes:
>
>> On Sun, Oct 2, 2022 at 12:34 PM Philip Kaludercic <philipk@posteo.net>
>> wrote:
>>
>>>  The idea behind the name (Emacs polyGLOT) is not intuitive.
>>
>> Since when are names "intuitive"?  Do I have any intuition about who
>> you are or what you do from your name alone?  Names are abstract
>> indirections by definition (with some 20th century structuralist and
>> post-structuralist caveats that I really don't think apply here).
>
> Intuitive in the sense that you can reasonably infer information given
> previous experiences.  I know that [languagename]-mode is usually a
> major mode for a language.  A package name like "hl-diff" gives a rough
> idea of what the package is about, when you know that "hl" stands for
> highlight.  Something like "highlight-parentheses" is obvious.  If you
> know about VC, then "vc-fossil" is an intuitive name.
>
> In my opinion, non-intuitive names are among other things: bbdb, cape,
> cider, delight, ement, helm, rich-minority, tiny, ... (this is just a
> random selection from skimming through the package list)
>

All your examples are for libraries/modules with a very simple single
purpose. I don't think anyone disagrees it is good to have a name which
can assist in deducing the functionality. However, this isn't always
possible. It seems to be something very difficult for packages which
fulfil multiple functions or for packages where there are multiple
different implementations.

Consider templating libraries. I know of at least 4 fairly popular ones
- one of them, yasnippet even has 'ya' for 'yet another'. I saw a new
templating solution recently - what chance has that author got of
finding a name which is going to be intuitive and isn't already used or
will be confused with other packages with similar functionality? Even in
this discussion, we are struggling to find a good intuitive name
primarily because one of the most intuitive names (which also tends to
follow Emacs 'styule') has already been taken i.e. lsp-mode.

None of the names I've seen suggested are of any real improvement and in
many cases, I find them misleading as they imply a functionality which
the package does not provide. 

>> I have no problem admitting "Emacs polyglot" is mostly a half-assed pretext
>> to justify a distinctive, easy to type name. I wouldn't fixate on it.
>>
>> Some people like its sound and uniqueness.  A demographic you are not part
>> of, I comprehend that. You can't always please everyone.
>
> I get that.
>
>>> I don't even think it is necessary to rename the implementation as long
>>> as at least one auto-loaded alias is available.
>>
>> What is this idea? Say you make M-x philip an auto-loaded alias for M-x
>> eglot.
>
> Where "M-x philip" is a stand-in for some of the suggestions I made
> before like "M-x ide-mode"?
>
>> Say I go with that, then what?  What about M-x eglot-rename, M-x
>> eglot-reconnect,
>> M-x eglot-shutdown and all the eglot- user variables, etc?
>> They keep the same names? What good is that really?  Alias all of them?
>> No thanks, there are enough confused users already: I want to communicate
>> with them as unequivocally as possible
>
> 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? 

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

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.

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