RE: Improving browsing and discoverability in the Packages Menu

[Drew Adams]

(Sure wish you would send your emails as plain text, BTW.)

> > > 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)?
> The idea is not to restrict or prevent anything, just recommend.
> We would extend the list of known finder.el keywords. When the byte
> compiler is compiling a package, it could issue a warning if it
> notices keywords that are not part of the known list.

I for one (perhaps the only one) would object to that.  There is no
reason to "warn" users about libraries that are not doing anything
even potentially wrong - and that includes using `Keywords' in a
file header that you might never have heard of.

Again.  File headers with keyword `Keywords' have been around for
decades.  `Keywords' is for any keywords whatsoever.  It does not
belong to package.el.

I suggested, and suggest again, that if you are going to take such
a proprietary and controlling attitude toward package.el-recognizable
keywords then package.el should add and use its own file-header
keyword, e.g., `Package Keywords' - and leave the long-existing (and
used) keyword `Keywords' alone.

> All keywords would keep working just the same (even those not on
> the list).

"Warning" users about keywords you don't recognize does not mean
that things "keep working just the same".  Forget about the warning,
if you want to pretend that things will "keep working just the same".

> This warning would be the only change here.

That's one change too much.  Have package.el do it in its own
backyard: `Package Keywords'.  Or don't have it do it at all.

> The intention was to nudge developers towards avoiding useless
> duplicates. 

Duplicates as far as package.el is concerned.  That doesn't mean
duplicates as far as every use/program is concerned.

I have no problem with package.el doing whatever it wants, in its
own territory.  But if it wants to start using existing keywords,
such as `Keywords', then it needs to play well with the others
who are already in the same sandbox.  It can't just move in and
claim the sandbox for its own.

> We wouldn't enforce anything.

The warning is uncalled for, if this is about `Keywords'.  It
can be appropriate, if it is about some new file-header keyword.

> I agree the keywords system should never become restricted, but
> I do think we need to help developers towards standardising it
> a little.

The problem is that you are referring to "the keywords system".
And you are trying to shove it into a particular use case.

File-header fields (keywords) that have been around for quite
some time should be left as is (and this should have included
`Version').  You can add whatever other fields you like, and
make their use as restrictive or helpful with as many warnings
or preventions as you like.  No problem.