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: Tue, 21 Apr 2015 08:44:30 -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> <87lhhmgeht.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 1429631114 4625 80.91.229.3 (21 Apr 2015 15:45:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Apr 2015 15:45:14 +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 17:45:02 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 1YkaM8-0003uy-1g for ged-emacs-devel@m.gmane.org; Tue, 21 Apr 2015 17:45:00 +0200 Original-Received: from localhost ([::1]:59201 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkaM7-00085P-82 for ged-emacs-devel@m.gmane.org; Tue, 21 Apr 2015 11:44:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkaLt-000856-80 for emacs-devel@gnu.org; Tue, 21 Apr 2015 11:44:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkaLn-0005cy-Cg for emacs-devel@gnu.org; Tue, 21 Apr 2015 11:44:45 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:44165) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkaLn-0005bG-71; Tue, 21 Apr 2015 11:44:39 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t3LFiVFk013783 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Apr 2015 15:44:32 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t3LFiUg9020241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Apr 2015 15:44:31 GMT Original-Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t3LFiU5L012832; Tue, 21 Apr 2015 15:44:30 GMT In-Reply-To: <87lhhmgeht.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: userv0021.oracle.com [156.151.31.71] 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:185754 Archived-At: > >> 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? >=20 > No, what I've meant to say is that when a maintainer adds the new > `Package Keywords' header duplicating the existing `Keywords' header and > then sees that byte-compilation suggests to use the more commonly used > "mode-line" and "email" instead of "modeline" and "electronic mail", why > should she change only `Package Keywords` accordingly and not > `Keywords', too? (Assuming that she agrees that "mode-line" and "email" > express what she intended to express, too.) If package.el continues to issue warnings for stuff that is in `Keywords' (not `Package Keywords'), then it is not playing fair. In that case it would have created its own sandbox (good) but continue to poke its nose into the old community sandbox, kick sand around, and annoy its occupants with bullying warnings and such (bad). If not, then there should be no problem. Keywords inserted in `Package Keywords' should obey the new rules - or else warnings & helpful electroshock will duly ensue, per spec. If someone blindly copies existing non-package keywords from `Keywords' to `Package Keywords', and if some of those flaunt the clean, Streng Verboten rules of package.el, then the copier gets what s?he deserves: appropriate insults (er, guidance) from package.el. > She doesn't know that there are some people that don't want `Keywords' > to be changed. Or should the warning say something like that? Yes, `Keywords' is not for package keywords. That should be part of=20 the message for users (the doc). `Package Keywords', and only `Package Keywords', is for package keywords, which have (whatever) strict semantics. Not a big deal. Clean, tidy. Should make parsing and controlling by package.el easy, without stepping on any toes - no sand in eyes. `Keywords' need not (& should not) be mentioned in the package doc. But if it is, just say that it is lax - no special semantics. The message should be only that keywords related to packages belong in `Package Keywords' - that's all. There is no mention of `Keywords' in the current Emacs manual, and no need to add any mention of it (IMO). Search case-sensitively for `Keywords' in the Emacs manual and - guess what? - you find hits only for (drum roll...) `Package Keywords'. Seems that Ms Manual has already paved the way for my suggestion. Oh, but the Elisp manual mentions `Keywords' in its discussion of packages. What it says there (node `Simple Packages') is only specific to use of `Keywords' by package.el. This text should refer instead to `Package Keywords', of course. The Elisp manual mentions `Keywords' also in node `Library Headers'. And (guess what?) there the text mentions the use of `Keywords' by `finder-by-keyword' - which is NOT and should NOT be limited to packages as defined by package.el. That is all as it should be. Unfortunately, the description of `Keywords' in node `Library Headers' has been updated to mention that it is now used also by package.el. That is inappropriate and should be cleaned up. Instead of saying this: The name of this field is unfortunate, since people often assume it is the place to write arbitrary keywords that describe their package, rather than just the relevant Finder keywords. The correct approach here is to use a new, NOT-unfortunate name for package keywords, and continue to let `finder-by-keyword' and any other longstanding code use `Keywords' as originally intended (no special rules, syntax, or relations). Just as finder.el is not (& should not be made to be) limited to what is good for package.el (both `finder-known-keywords' and `finder-list-keywords' predate package.el), so should file-header keyword `Keywords' not be limited to package.el relevance. > The Package Keywords entry "modeline" is likely to mean "mode-line". > If you agree, change it accordingly but please let the Keywords > header as-is for the Olt Town's habitants peace of mind. I'd say just mention what `Package Keywords' is for in the doc, and not repeat the doc in each warning about package keywords. But you know better than I what warnings people should be scared with. ;-)