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 11:17:52 -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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1429553901 9713 80.91.229.3 (20 Apr 2015 18:18:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Apr 2015 18:18:21 +0000 (UTC) Cc: Alexis , emacs-devel To: bruce.connor.am@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 20 20:18:10 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 1YkGGn-0004b6-MW for ged-emacs-devel@m.gmane.org; Mon, 20 Apr 2015 20:18:09 +0200 Original-Received: from localhost ([::1]:54899 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkGGn-0005Wn-1Y for ged-emacs-devel@m.gmane.org; Mon, 20 Apr 2015 14:18:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34542) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkGGk-0005Wa-0y for emacs-devel@gnu.org; Mon, 20 Apr 2015 14:18:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkGGe-0004J2-NW for emacs-devel@gnu.org; Mon, 20 Apr 2015 14:18:05 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:37523) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkGGe-0004Iu-GT for emacs-devel@gnu.org; Mon, 20 Apr 2015 14:18:00 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t3KIHrAj012838 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Apr 2015 18:17:53 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t3KIHqMc000640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 Apr 2015 18:17:53 GMT Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t3KIHqje029851; Mon, 20 Apr 2015 18:17:52 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:185723 Archived-At: (Sure wish you would send your emails as plain text, BTW.) > > > We would just accept any keyword that doesn't already have... > > > > "We" is what here, exactly?=C2=A0 Just the use of keywords by > > `list-packages' (or other package viewing/filtering code)? > The idea is not to restrict or prevent anything, just recommend. > We would extend the list of known finder.el keywords. When the byte > compiler is compiling a package, it could issue a warning if it > notices keywords that are not part of the known list. I for one (perhaps the only one) would object to that. There is no reason to "warn" users about libraries that are not doing anything even potentially wrong - and that includes using `Keywords' in a file header that you might never have heard of. Again. File headers with keyword `Keywords' have been around for decades. `Keywords' is for any keywords whatsoever. It does not belong to package.el. I suggested, and suggest again, that if you are going to take such a proprietary and controlling attitude toward package.el-recognizable keywords then package.el should add and use its own file-header keyword, e.g., `Package Keywords' - and leave the long-existing (and used) keyword `Keywords' alone. > All keywords would keep working just the same (even those not on > the list). "Warning" users about keywords you don't recognize does not mean that things "keep working just the same". Forget about the warning, if you want to pretend that things will "keep working just the same". > This warning would be the only change here. That's one change too much. Have package.el do it in its own backyard: `Package Keywords'. Or don't have it do it at all. > The intention was to nudge developers towards avoiding useless > duplicates.=20 Duplicates as far as package.el is concerned. That doesn't mean duplicates as far as every use/program is concerned. I have no problem with package.el doing whatever it wants, in its own territory. But if it wants to start using existing keywords, such as `Keywords', then it needs to play well with the others who are already in the same sandbox. It can't just move in and claim the sandbox for its own. > We wouldn't enforce anything. The warning is uncalled for, if this is about `Keywords'. It can be appropriate, if it is about some new file-header keyword. > I agree the keywords system should never become restricted, but > I do think we need to help developers towards standardising it > a little. The problem is that you are referring to "the keywords system". And you are trying to shove it into a particular use case. File-header fields (keywords) that have been around for quite some time should be left as is (and this should have included `Version'). You can add whatever other fields you like, and make their use as restrictive or helpful with as many warnings or preventions as you like. No problem.