Re: [ELPA] New package: plz

[Adam Porter <adam@alphapapa.net>]

[-- Attachment #1: Type: text/plain, Size: 2178 bytes --]

On Sat, May 14, 2022, 18:58 Richard Stallman <rms@gnu.org> wrote:

> [[[ 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. ]]]
>
>   > And I think it doesn't matter here: if someone wonders what plz.el
> does,
>   > they can "C-h P plz RET" and find out.  And if someone is looking for
> an
>   > HTTP library, they can "M-x list-packages RET / d http RET" and find
> some.
>
> That is true -- but that only goes one way, from thinking about the
> name "plz" to trying to use it.  It does not help people go in the
> other direction, from an idea of doing something to thinking about using
> this one library.
>

I meant that searching the packages list by description would find
libraries related to HTTP.  I think this is okay, because purely
descriptive names tend to get long and unwieldy. They also tend to be less
memorable and distinctive in the long run.

>
The number of unclear package names in Emacs is a big problem (epa,
> eww, mml are a few examples out of many).  They are neither helpful
> nor funny, and they make those pakages undiscoverable.
>
> Let's not add any more of those.
>

I wouldn't propose merging a library into emacs.git with a cutesy name. I
agree that the names of core libraries should generally be descriptive and
straightforward.

OTOH, naming things is hard, and in this case, the obvious, descriptive
names are already taken. So I think that a longer, drier, purely
descriptive name would be less desirable for an ELPA package.

If I may say so, I also think that having lightly opinionated packages with
distinctive identities, and sometimes with mildly amusing names, can help
authors feel a sense of pride in their work, which can be motivating,
resulting in more and higher quality work, which ultimately benefits the
users. Of course, there is much value in having code in core rather than in
add-on packages, but at the same time, something can be lost when a project
is absorbed into a larger whole. A balance to be struck; a time for
everything; etc.

My two cents. :)

>

[-- Attachment #2: Type: text/html, Size: 3311 bytes --]