From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Improving browsing and discoverability in the Packages Menu Date: Mon, 20 Apr 2015 22:25:37 -0700 (PDT) Message-ID: References: <871tjgj010.fsf@ericabrahamsen.net> <7b3b0d19-01d4-4f97-b85e-19383bee5605@default> <87twwbdwjd.fsf@ericabrahamsen.net> <87d22zcde3.fsf@gmail.com> <60cf8797-6524-4bf3-8ff5-b8a74736eff6@default> <87zj62unvk.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1429593982 21812 80.91.229.3 (21 Apr 2015 05:26:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Apr 2015 05:26:22 +0000 (UTC) Cc: bruce.connor.am@gmail.com, emacs-devel To: Tassilo Horn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 21 07:26:06 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YkQhB-0008Pa-Nh for ged-emacs-devel@m.gmane.org; Tue, 21 Apr 2015 07:26:05 +0200 Original-Received: from localhost ([::1]:56297 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkQhA-0002Q7-KT for ged-emacs-devel@m.gmane.org; Tue, 21 Apr 2015 01:26:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39865) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkQgx-0002Pp-M7 for emacs-devel@gnu.org; Tue, 21 Apr 2015 01:25:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkQgr-0001N5-Sq for emacs-devel@gnu.org; Tue, 21 Apr 2015 01:25:51 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:39852) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkQgr-0001Mt-N4; Tue, 21 Apr 2015 01:25:45 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t3L5PclH015872 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Apr 2015 05:25:39 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t3L5PcVK025191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Apr 2015 05:25:38 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t3L5PbDi023507; Tue, 21 Apr 2015 05:25:38 GMT In-Reply-To: <87zj62unvk.fsf@gnu.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:185740 Archived-At: > >> 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. >=20 > 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. >=20 > 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. =20 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',...)