Re: Names are not descriptions; descriptions are not names

[Jim Porter]

On 5/12/2023 12:37 AM, Eli Zaretskii wrote:
> Again, there's no requirement to allow users distinguishing between
> similar packages just by looking at the name.  That can only be done
> by reading the package's description.
>
> IOW, the name should allow some kind of initial filtering: if I'm not
> interested in key translation, I don't need to look further at a
> package named key-transl.  It's the same first-order filtering we
> apply to email by just looking at the Subject.  Nothing more, nothing
> less.

Looking at the list of packages in GNU ELPA, almost all of them have a 
description well within the limits of what we'd expect from an email 
Subject. To use your example of "42", while that alone would be cryptic, 
a Subject like "42: The answer to life, the universe, and everything" 
would be ok, I think.

That being said, are there places we can make package descriptions more 
visible? Both "M-x list-packages" and the ELPA package list on the web 
show the descriptions prominently, so I find them both to be very easy 
to find packages, even if they have cryptic names. However, there may be 
further improvements we should make in this area. Packages can have 
keywords, so improving those might help, or maybe we could add metadata 
for broad package categories (e.g. "theme", "key bindings", "major 
mode", etc)...

Still, there's room for a light touch with improving package names 
(especially if we let the actual package *identifier* be a slight 
variation on the name). For example, the Devil package could otherwise 
stay the same, but we could give it a package identifier of 
"devil-keys". The functions and commands would still just be 
"devil-FOO", and the documentation could still say "devil" instead of 
"devil-keys" (except when talking about how to install the package, of 
course). Would that be a reasonable compromise for cases like this?