RE: Improving browsing and discoverability in the Packages Menu

[Drew Adams]

> We would just accept any keyword that doesn't already have...

"We" is what here, exactly?  Just the use of keywords by
`list-packages' (or other package viewing/filtering code)?

If so, I don't really care what you do in that regard.  I assume
it could be an improvement.

But if "we" here means Emacs in general or hints at a redirection
of the intention and flexible Emacs design of header keywords
and finder.el, then I'm not in favor.  Please solve your viewing
or filtering problems without touching file keywords or finder.el.

Do what you like on the viewing/filtering end, for package listing.
But please don't mess with the intention of file-header keywords,
which is *any* intention that anyone wants to give them, and which
at least includes *all* that finder.el can do with them.

> The point is not to be restrictive, but to prevent duplication
> like mail/email.

And what if someone has code that *wants* to distinguish keyword
`mail' from keyword `email'?  One person's (or one app's) handy
duplicate prevention can block another from taking advantage of
useful distinctions.  Eliminate what you consider duplication
at the consumer end, by filtering.  Please do not attempt to
impose a limitation on the source (`Keywords').  Filter; do not
"prevent".

Please don't restrict your thinking to your immediate task of
improving the `list-packages' UI.  Not if you are proposing
restrictions on header keywords or on what finder.el can do.

Filtering should not require redefining and redesigning the
things that are being filtered.  If the packages UI can't
figure out a way to easily let users match both `mail' and
`email', instead of preventing such "duplication" at the
source, then we're in deep trouble.  There should be no
requirement that the source code limit the keywords that
can be handled.

> We could also have some restriction like accepting at most
> 1 (or 2? 3?) new keyword request per package. 

What is a "keyword request" here?  Are you speaking only of
what a `list-packages' UI user can request?  Who or what is
requesting a keyword from who or what?

> Might such a process result in emacs-devel being flooded
> with interminable ontological bikeshedding?

Why should what can end up in a file-header `Keywords' list
concern emacs-devel at all?

Leave it alone.  Figure out whatever you like for users to 
access/search/filter/view keywords for a list of packages,
but please do not try to impose restrictions on what users
and other code can use for file-header keywords.

Emacs is always much bigger than the part of it that you are
currently thinking of improving.

(And yes, it is bigger than what is developed by emacs-devel
and distributed as part of GNU Emacs.)

> Possibly. New packages are created at a rate of a few per
> day. It's hard to say how many new keywords that entails.

It shouldn't matter.  At all.  Even just for filtering for
the UI that lists packages, IMO.  But especially beyond that
*one* use of file-header keywords.

File headers are not only for package.el (and not only for
finder.el, for that matter).  Package.el has come late to
the file-headers (including `Keywords') party.

But it is welcome to join, as long as it respects the other
partygoers.  And it doesn't matter how many packagers it
brings through the front door.  They should realize that
the party is not only for them.

They could of course start their own party elsewhere, using
their own `Package Keywords' or some such.  Or they can just
learn to get along with others at the same `Keywords' party.

(There have already been attempts to give `Version' a new,
restricted interpretation.  Fortunately, so far such
restrictions apply only to use by package.el, and not to
some general redefinition of what `Version' might be for.)

> Somebody could estimate it based on Melpa git history.

Waste of time, IMO.  And likely to misguide.