RE: Improving browsing and discoverability in the Packages Menu

[Drew Adams <drew.adams@oracle.com>]

> >> For instance, there are 3 different mode-line keywords: mode-line,
> >> modeline, and mode line. The last two contain a single package each,
> >> both of which will not show up if the user looks for the "mode-line"
> >> keword...
> >
> > Yes, it's a bother.  But there is no way to know what is a typo or
> > negligence and what is intentional difference, e.g. required by some
> > particular code or context.
> 
> If it were intended by the package author, where is the problem of
> adding
>   ;; byte-compile-warnings: (not unknown-keyword)
> to the package's local variables section?

So to some file written by someone somewhere somewhen, perhaps
quite some time ago, you say: "All ya gotta do is jump through
this leetle hoop here."

I say, "All ya gotta do is stay away from `Keywords', which has
been around forever.  Just go and roll yer own!  Problem solved."

Ya name it `Package Keywords' or `Kate's Categories' or whatever.
End of story - poof, no problem.

Just don't try to hijack `Keywords', which Emacs has been using
for a long long time without additional rules, and stomp on its
users with a fancy set of patterns and relations that fit your
shiny new app (`package.el').  There's no call for that, no need.

It's pretty simple really.  Create your own sandbox.

(I don't mean you personally, of course.  I hope you get the idea.)

> > That's why I suggest that you start out with a new, fresh field, which
> > you announce as pretty much dedicated to package.el and which will be
> > controlled by it.
> 
> I don't see why `Keywords' shouldn't be appropriate for elisp programs
> installable via package.el.

It could be, if package.el behaved and played well with others.

But if it comes storming into the sandbox and cries that everyone
needs to play by the rules of a new game it's invented, that's
not fair.  It is only because it menaces now to start shoving
others around, tossing sand in faces, that one is inclined to
suggest politely, "Please go play over there, nicely, in your
own sandbox, if you can't get along here."

> It's not that it re-defines its meaning.

Sure it is.  If it is starting to say what's a duplicate and
what's not.  And it's even trying to "prevent" duplication (as
it sees it).

It's imposing a new world order on the little sandbox.  And there
is no need - plenty of room for it to play on its own in its own
shiny new sandbox.  It can invent and refine rules to fit its own
uses perfectly, with no noise or interference from anyone else.

> The benefit of using it is that it's already there most of the
> time.  

Ay, but there's the rub.  Instead of building (and how much
effort does it really take?) its own sandbox, it'd rather usurp
the community one in Old Town.  Step in, set some rules, issue
some warnings if they're not respected...  There's a new sheriff
in town - move along.

> A new field would take some time to get picked up.

Oh, please.  You underestimate the power of Emacs Dev.
We're already hearing that users should be told to no
longer put `require' in their init files.

`package.el' has already taken over most of the playground.
It won't be a big deal for it to build a new sandbox in one
corner that lots of kids will want to play in - especially
the new kids.  It won't be playing alone for long, trust me.

> And I'm pretty sure you won't see any occurrence of
>   ;; Keywords: modeline, electronic mail
>   ;; Package Keywords: mode-line, email
> even if there was a new field.

Sorry, I didn't catch your last point.  Perhaps you mean
to say that `Keywords' will disappear?  All the kids will
run to play in the new sandbox?

Maybe so.  But the old one will pass with a whimper in that
case, not a bang.  No sand in faces. No confusion in the
meantime, no adapting, no messy cleanup.  Peaceful coexistence.

I'd even go so far as to suggest that *each* file-header
keyword that package.el wants to use, and possibly give
special some semantics (order) to, should use the same prefix:
`Package Version', `Package Requires', `Package Keywords',...

Why not?

No confusion, complete control over its own needs and wishes.
Clean and simple.  No wrestling with what might have been
used here or there for `Version' or `Keywords' or...  Easily
recognizable for what it is: something to do with, uh, packages.

Try it.  I'll bet you a pint of whatever that if you create
the `Package Keywords' sandbox today, write up its Robert's
Rules of Order, and implement whatever enforcements or
reminders/warnings you think might be helpful...  By the
time you can say `Kate's Categories' it will be the most
popular act on the file-header circuit.  Better mousetrap,
beaten path.

(Oh, it's `Package-Requires', not `Package Requires'?
No special need for that hyphen, but so be it:
`Package-Version', `Package-Keywords',...)