RE: Adding a few more finder keywords

[Drew Adams]

> > Again, let it do those things with a new file-header keyword.
> > If some of the things finder will do are the same, then let it
> > do them with both `Keywords:' and the new file-header keyword.
> > IOW, to the extent that some part of the updated finder does not
> > conflict with the normal interpretation/use of `Keywords:', let
> > it be used for both.
> 
> I disagree. Redundancy leads to misuse and under-use.

No one is proposing redundancy.  You are trying to co-opt `Keywords:'
for a different use, effectively imposing/encouraging/warning-about
restrictions on what it should contain.  That's not the same thing -
no redundancy.

> And it's a pain to parse.

Why should parsing your new file-header keyword be any more
painful than parsing the longstanding and differently purposed
keyword `Keywords:'?

> Using `Keywords:' for tagging sections is good because most
> files need not be touched: they're already fine.

Laziness!

And anyway, nothing says that you cannot *also* parse `Keywords:'
for your particular use.  What you should not do is interpret the
meaning of its keywords as only applying to your use case.  You
should not warn users just because you encounter something in
`Keywords:' that you don't recognize or don't like.  You don't
own that field.

IOW, if you want to go ahead and look at `Keywords:', in addition
to your new file-header field, to look for certain "recommended"
keywords, that's your prerogative.

What you should not do is impose on other keywords in `Keywords:'
your use-case interpretation of them being aliens, not recognized,
or illegitimate.

For your new file-header keyword, you can impose any semantics
you like.  But not for `Keywords:'.  Blaring warning sirens
because you find something in `Keywords:' that you don't like
or recognize is a no-no, IMHO.  That's OK for your own field,
but not for the longstanding shared field `Keywords:'.  That
doesn't prevent you from examining `Keywords:', e.g., looking
for keywords that are acceptable to you.

> On the other hand, if we introduce something like:
>     ;; Section: python
> with a tight list of exclusive sections (a file can belong to only
> one section), I'd be fine with that.

Go for it.  A priori, I have no opinion about what you do with
any new file-header keyword you introduce.

> there are more than 1000 unique keywords for 2000 packages.

So what?

> Having so many unique keywords hampers their functionality.

Hampers the particular functionality you have in mind, perhaps.

There are maybe 500 or 1000 different functionalities that users
have created for those 1000 unique keywords - who knows?  And who
cares?  Users are free to use `Keywords:' however they want.

If their uses of `Keywords:' hamper the functionality you have
in mind, there is a very simple solution: you should not expect
`Keywords:' to do only what you want.  It can do anything.

If you need a restrictive, nailed-down file-header keyword then
the simple solution is obvious: come up with your own.  Don't
try to take over the one that the other boys & girls have been
happily sharing for a very long time.

> We just need to select a group of keywords that are deemed
> "important" and make it easy to see all "important"
> keywords at once and browse them.

Just don't do that to `Keywords:'.  Decide such importance for
your own shiny new file-header field.

> I don't see how defining a subset of "important" ~50 keywords among
> the current ~1000 keywords in use is doing anything against the "more
> flexible" use cases.

It's what you intend for the "unimportant" keywords that conflicts
with the longstanding use of `Keywords:'.  You intend to issue
warnings and such (whatever the means used and the effect).

That's not right.  Just create your own sandbox and leave the old,
messy long-shared sandbox alone.  Everyone will be happy.  You will
be able to completely control your new zone, keeping it squeaky
clean, and those dirty kids will still be able to play their same
old scrappy games in the old sandbox.  They won't bother you, and
you won't bother them.

> Basically, I want something like `finder-list-keywords' to work for
> all packages managed by package.el as well.

No problem; go for it.  I would like something like that too.

> I think it would be a great interface to complement
> `package-list-packages'. Maybe call it `package-list-categories'.

Again, I'm all in favor.

You know, `finder.el' is not just about `Keywords:'.  It deals also
with `Commentary:' and does some other things.

And more importantly, `Keywords:' is not just about what `finder.el'
does with it.  `finder.el' is one feature that can make use of
`Keywords:'.  It came along after `Keywords:' existed, as an idea
by ESR of one thing that could be done usefully with existing Emacs
file headers.

It is fine to add functionality to `finder.el', to more specifically
support the new package system.  (It would also be OK to do that in
some other library, instead of `finder.el'.)

What should not happen is that someone comes along and reinterprets
`Keywords:' or `Commentary:' or any longstanding file-header thingy,
imposing new restrictions on what to expect there.  That should be
verboten.

We already saw this happen, unfortunately, to the longstanding
file-header keyword `Version:'.  That free-form field has now
been compromised, by misguided influence from the new package
system.  What should have been done in that case was to add a new
file-header keyword, just for the package system, with whatever
nice, tight restrictions are appropriate for it.  That correct
approach was taken for `Package-Requires:', thank goodness, but
alas not for `Version:'.  We should learn from that mistake.

It is all too tempting to try to co-opt some existing field,
perhaps especially if `finder.el' already does something with it
that you find useful and extensible in your direction.  Ignore
the temptation.  Assume that others are using that existing
field in ways that don't necessarily fit your plans.  Leave it
alone - move on.

If you need something new, then add something new.  Don't
compromise existing constructs that others have been happily
using in ways you don't approve of or cannot make use of.
Share the road.