Re: plz -> curl?

[Po Lu <luangruo@yahoo.com>]

Adam Porter <adam@alphapapa.net> writes:

> Users who don't know how to use the package system will not be
> installing the package in the first place.

It is better for a package name to be helpful than for it to be merely
possible for the user to install it.

> Those packages have distinctive identities to those who use
> them. Giving them generic names does not help the user remember them;
> it has the opposite effect.

A package on ELPA or NonGNU ELPA doesn't exist so that they can have a
distinctive identity, it exists to be helpful to users.  Giving a
package a name that fails to describe what it does is not helpful,
especially one as cryptic as "plz" or "eglot".

If you ask for the apropos of "language server" or "lsp" with Eglot
installed, there are no results.  Browsing the package list is also less
useful, since there are many packages and reading the descriptions for
each one of them sometimes takes too long.

> As I said, I don't want to use that name, because it implies more
> comprehensive support for curl than I intend to provide in the
> library.  As well, there are other packages that provide a front end
> to curl.

Then how about "external-http-client"?  That says it is a client for
HTTP using an external program, but doesn't mention curl by name.

> As I've said, long, purely descriptive package names like that are
> less useful in the long run, as well as simply being too long.

That simply doesn't make sense.  A package with a descriptive name will
be more useful in the long run, because users will find it easier to
remember, and its purpose will be obvious to anyone reading code that
uses it.

I think we should simply not accept packages with nondescript names in
ELPA or NonGNU ELPA in the future, since listing them is a disservice
and serves to encourage the practice of naming packages confusingly.