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: Sun, 19 Apr 2015 07:58:39 -0700 (PDT) Message-ID: <7b3b0d19-01d4-4f97-b85e-19383bee5605@default> References: <871tjgj010.fsf@ericabrahamsen.net> 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 1429455565 16794 80.91.229.3 (19 Apr 2015 14:59:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Apr 2015 14:59:25 +0000 (UTC) To: Eric Abrahamsen , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 19 16:59:11 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 1Yjqge-00054O-Lt for ged-emacs-devel@m.gmane.org; Sun, 19 Apr 2015 16:59:08 +0200 Original-Received: from localhost ([::1]:48790 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yjqgd-0001M5-P5 for ged-emacs-devel@m.gmane.org; Sun, 19 Apr 2015 10:59:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46218) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjqgS-0001Lp-0f for emacs-devel@gnu.org; Sun, 19 Apr 2015 10:58:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YjqgM-0003Kd-TJ for emacs-devel@gnu.org; Sun, 19 Apr 2015 10:58:55 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:17791) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjqgM-0003Jo-Ns for emacs-devel@gnu.org; Sun, 19 Apr 2015 10:58:50 -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 t3JEwlNA029074 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 19 Apr 2015 14:58:48 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t3JEwkZF010175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 19 Apr 2015 14:58:47 GMT Original-Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t3JEwkv8025142; Sun, 19 Apr 2015 14:58:46 GMT In-Reply-To: <871tjgj010.fsf@ericabrahamsen.net> 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:185666 Archived-At: > This would be nice to fix. `finder-known-keywords' looks like the > place to start. Package filtering is only indirectly connected to the > value of that variable, though. >=20 > Filtering is done on keywords actually found in the packages. If > package authors used `auto-insert' when creating their packages, > they would be prompted to add keywords from `finder-known-keywords'. > That leaves a lot of wiggle room for the insertion of random keywords. I'm not sure what you meant by the last part, so this comment might be unrelated to your post. But I would like to remind us all that `finder' functionality is not limited to the keywords found in `finder-known-keywords'. Users can use any keywords they like in their library headers. I would not like to see `finder.el' gravitate toward imposing some particular set of keywords or expecting only some particular set. > In order to make filtering useful, it seems like it would be > worthwhile fleshing out the taxonomy of `finder-known-keywords', > and enforcing it -- ie, keywords not in that variable would be > ignored by package filtering. I'm not sure I would object to something like that being done only "by package filtering". But I would object to changing the point of `finder.el' so that it generally becomes more rigid in that way. Even for only "package filtering", I have the question of why. Why should package filtering be limited to some predefined list of keywords? Just why should "keywords not in that variable... be ignored by package filtering"?