[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Improving browsing and discoverability in the Packages Menu

From: Drew Adams
Subject: RE: Improving browsing and discoverability in the Packages Menu
Date: Mon, 20 Apr 2015 13:30:48 -0700 (PDT)

> > (Sure wish you would send your emails as plain text, BTW.)
> Haven't figured out how to that on my phone yet (so I'm switching to
> the laptop just for you ;-). 

Thank you.  (And I'll bet I'm not the only one who appreciates it.)

> If it's any consolation, your pre-filled emails look terrible on
> my phone too. :-)

If it's any consolation, they're not even prefilled.  I do it myself.

> Thanks. I do see your point in all of that.I just wish we had some way
> to polish things out a little bit.f This not even for the sake of
> package.el, but for the keywords as a whole.

I would say to concentrate on what package.el needs.  And in particular,
to consider having it do whatever it thinks helps it, but in its own
header keyword (field), not in `Keywords'.  IOW, start clean, from
scratch, and impose any rules and checking you want.

> 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.

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.

With that announcement, you are free to ignore or correct or raise
an error for anything that doesn't fit the mold.

And with a little encouragement from such checks (e.g. errors),
library authors will learn to DTRT.

My only point was that it is not wise to try to usurp `Keywords'
for this.  Too much history, too long.  Too much out there already,
at least potentially, in the form of various usages and expectations.

> I understand a warning may not be the way of doing that, but it would
> be nice if we could help developers standardize these a little. And
> I'll appreciate further suggestions.

See above.  Hands off `Keywords' and you're free to do whatever
you think helps in this regard.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]