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: Adding a few more finder keywords Date: Tue, 9 Jun 2015 09:05:40 -0700 (PDT) Message-ID: <6cb2edd7-dfca-41ab-b3cb-e09e29b39a94@default> References: <87sia2l04r.fsf@gmail.com> <873821xzon.fsf@uwakimon.sk.tsukuba.ac.jp> <048d389e-cd09-468e-b93f-729505e56ab0@default> <87zj49kkff.fsf@gmail.com> 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 1433865992 8471 80.91.229.3 (9 Jun 2015 16:06:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Jun 2015 16:06:32 +0000 (UTC) Cc: "Stephen J. Turnbull" , Stefan Monnier , Artur Malabarba , emacs-devel To: Oleh Krehel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 09 18:06:18 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 1Z2M2Y-0005IW-Rx for ged-emacs-devel@m.gmane.org; Tue, 09 Jun 2015 18:06:15 +0200 Original-Received: from localhost ([::1]:36066 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2M2X-0008Dr-Rb for ged-emacs-devel@m.gmane.org; Tue, 09 Jun 2015 12:06:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44110) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2M2F-0008Df-A2 for emacs-devel@gnu.org; Tue, 09 Jun 2015 12:05:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z2M29-0001uD-Tq for emacs-devel@gnu.org; Tue, 09 Jun 2015 12:05:55 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:22358) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2M29-0001tv-Nf for emacs-devel@gnu.org; Tue, 09 Jun 2015 12:05:49 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t59G5fRW029570 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Jun 2015 16:05:42 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t59G5f1i016738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 9 Jun 2015 16:05:41 GMT Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t59G5fTj001653; Tue, 9 Jun 2015 16:05:41 GMT In-Reply-To: <87zj49kkff.fsf@gmail.com> 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: 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:187129 Archived-At: > > Again, let it do those things with a new file-header keyword. > > If some of the things finder will do are the same, then let it > > do them with both `Keywords:' and the new file-header keyword. > > IOW, to the extent that some part of the updated finder does not > > conflict with the normal interpretation/use of `Keywords:', let > > it be used for both. >=20 > I disagree. Redundancy leads to misuse and under-use. No one is proposing redundancy. You are trying to co-opt `Keywords:' for a different use, effectively imposing/encouraging/warning-about restrictions on what it should contain. That's not the same thing - no redundancy. > And it's a pain to parse. Why should parsing your new file-header keyword be any more painful than parsing the longstanding and differently purposed keyword `Keywords:'? > Using `Keywords:' for tagging sections is good because most > files need not be touched: they're already fine. Laziness! And anyway, nothing says that you cannot *also* parse `Keywords:' for your particular use. What you should not do is interpret the meaning of its keywords as only applying to your use case. You should not warn users just because you encounter something in `Keywords:' that you don't recognize or don't like. You don't own that field. IOW, if you want to go ahead and look at `Keywords:', in addition to your new file-header field, to look for certain "recommended" keywords, that's your prerogative. What you should not do is impose on other keywords in `Keywords:' your use-case interpretation of them being aliens, not recognized, or illegitimate. For your new file-header keyword, you can impose any semantics you like. But not for `Keywords:'. Blaring warning sirens because you find something in `Keywords:' that you don't like or recognize is a no-no, IMHO. That's OK for your own field, but not for the longstanding shared field `Keywords:'. That doesn't prevent you from examining `Keywords:', e.g., looking for keywords that are acceptable to you. > On the other hand, if we introduce something like: > ;; Section: python > with a tight list of exclusive sections (a file can belong to only > one section), I'd be fine with that. Go for it. A priori, I have no opinion about what you do with any new file-header keyword you introduce. > there are more than 1000 unique keywords for 2000 packages. So what? > Having so many unique keywords hampers their functionality. Hampers the particular functionality you have in mind, perhaps. There are maybe 500 or 1000 different functionalities that users have created for those 1000 unique keywords - who knows? And who cares? Users are free to use `Keywords:' however they want. If their uses of `Keywords:' hamper the functionality you have in mind, there is a very simple solution: you should not expect `Keywords:' to do only what you want. It can do anything. If you need a restrictive, nailed-down file-header keyword then the simple solution is obvious: come up with your own. Don't try to take over the one that the other boys & girls have been happily sharing for a very long time. > We just need to select a group of keywords that are deemed > "important" and make it easy to see all "important" > keywords at once and browse them. Just don't do that to `Keywords:'. Decide such importance for your own shiny new file-header field. > I don't see how defining a subset of "important" ~50 keywords among > the current ~1000 keywords in use is doing anything against the "more > flexible" use cases. It's what you intend for the "unimportant" keywords that conflicts with the longstanding use of `Keywords:'. You intend to issue warnings and such (whatever the means used and the effect). That's not right. Just create your own sandbox and leave the old, messy long-shared sandbox alone. Everyone will be happy. You will be able to completely control your new zone, keeping it squeaky clean, and those dirty kids will still be able to play their same old scrappy games in the old sandbox. They won't bother you, and you won't bother them. > Basically, I want something like `finder-list-keywords' to work for > all packages managed by package.el as well. No problem; go for it. I would like something like that too. > I think it would be a great interface to complement > `package-list-packages'. Maybe call it `package-list-categories'. Again, I'm all in favor. You know, `finder.el' is not just about `Keywords:'. It deals also with `Commentary:' and does some other things. And more importantly, `Keywords:' is not just about what `finder.el' does with it. `finder.el' is one feature that can make use of `Keywords:'. It came along after `Keywords:' existed, as an idea by ESR of one thing that could be done usefully with existing Emacs file headers. It is fine to add functionality to `finder.el', to more specifically support the new package system. (It would also be OK to do that in some other library, instead of `finder.el'.) What should not happen is that someone comes along and reinterprets `Keywords:' or `Commentary:' or any longstanding file-header thingy, imposing new restrictions on what to expect there. That should be verboten. We already saw this happen, unfortunately, to the longstanding file-header keyword `Version:'. That free-form field has now been compromised, by misguided influence from the new package system. What should have been done in that case was to add a new file-header keyword, just for the package system, with whatever nice, tight restrictions are appropriate for it. That correct approach was taken for `Package-Requires:', thank goodness, but alas not for `Version:'. We should learn from that mistake. It is all too tempting to try to co-opt some existing field, perhaps especially if `finder.el' already does something with it that you find useful and extensible in your direction. Ignore the temptation. Assume that others are using that existing field in ways that don't necessarily fit your plans. Leave it alone - move on. If you need something new, then add something new. Don't compromise existing constructs that others have been happily using in ways you don't approve of or cannot make use of. Share the road.