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 07:32:31 -0700 (PDT) Message-ID: <60cf8797-6524-4bf3-8ff5-b8a74736eff6@default> References: <871tjgj010.fsf@ericabrahamsen.net> <7b3b0d19-01d4-4f97-b85e-19383bee5605@default> <87twwbdwjd.fsf@ericabrahamsen.net> <87d22zcde3.fsf@gmail.com> 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 1429540409 31010 80.91.229.3 (20 Apr 2015 14:33:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Apr 2015 14:33:29 +0000 (UTC) Cc: emacs-devel To: bruce.connor.am@gmail.com, Alexis Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 20 16:33:17 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 1YkClB-0004ha-6S for ged-emacs-devel@m.gmane.org; Mon, 20 Apr 2015 16:33:17 +0200 Original-Received: from localhost ([::1]:53932 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkClA-0001PQ-Kb for ged-emacs-devel@m.gmane.org; Mon, 20 Apr 2015 10:33:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33684) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkCkk-0000vy-3g for emacs-devel@gnu.org; Mon, 20 Apr 2015 10:32:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkCke-0007Sj-6I for emacs-devel@gnu.org; Mon, 20 Apr 2015 10:32:50 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:17123) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkCkd-0007SV-PZ for emacs-devel@gnu.org; Mon, 20 Apr 2015 10:32:44 -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 t3KEWenZ031191 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Apr 2015 14:32:41 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t3KEWekY028944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 Apr 2015 14:32:40 GMT Original-Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t3KEWetO028807; Mon, 20 Apr 2015 14:32:40 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: 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:185703 Archived-At: > We would just accept any keyword that doesn't already have... "We" is what here, exactly? Just the use of keywords by `list-packages' (or other package viewing/filtering code)? If so, I don't really care what you do in that regard. I assume it could be an improvement. But if "we" here means Emacs in general or hints at a redirection of the intention and flexible Emacs design of header keywords and finder.el, then I'm not in favor. Please solve your viewing or filtering problems without touching file keywords or finder.el. Do what you like on the viewing/filtering end, for package listing. But please don't mess with the intention of file-header keywords, which is *any* intention that anyone wants to give them, and which at least includes *all* that finder.el can do with them. > The point is not to be restrictive, but to prevent duplication > like mail/email. And what if someone has code that *wants* to distinguish keyword `mail' from keyword `email'? One person's (or one app's) handy duplicate prevention can block another from taking advantage of useful distinctions. Eliminate what you consider duplication at the consumer end, by filtering. Please do not attempt to impose a limitation on the source (`Keywords'). Filter; do not "prevent". Please don't restrict your thinking to your immediate task of improving the `list-packages' UI. Not if you are proposing restrictions on header keywords or on what finder.el can do. Filtering should not require redefining and redesigning the things that are being filtered. If the packages UI can't figure out a way to easily let users match both `mail' and `email', instead of preventing such "duplication" at the source, then we're in deep trouble. There should be no requirement that the source code limit the keywords that can be handled. > We could also have some restriction like accepting at most > 1 (or 2? 3?) new keyword request per package.=20 What is a "keyword request" here? Are you speaking only of what a `list-packages' UI user can request? Who or what is requesting a keyword from who or what? > Might such a process result in emacs-devel being flooded > with interminable ontological bikeshedding? Why should what can end up in a file-header `Keywords' list concern emacs-devel at all? Leave it alone. Figure out whatever you like for users to=20 access/search/filter/view keywords for a list of packages, but please do not try to impose restrictions on what users and other code can use for file-header keywords. Emacs is always much bigger than the part of it that you are currently thinking of improving. (And yes, it is bigger than what is developed by emacs-devel and distributed as part of GNU Emacs.) > Possibly. New packages are created at a rate of a few per > day. It's hard to say how many new keywords that entails. It shouldn't matter. At all. Even just for filtering for the UI that lists packages, IMO. But especially beyond that *one* use of file-header keywords. File headers are not only for package.el (and not only for finder.el, for that matter). Package.el has come late to the file-headers (including `Keywords') party. But it is welcome to join, as long as it respects the other partygoers. And it doesn't matter how many packagers it brings through the front door. They should realize that the party is not only for them. They could of course start their own party elsewhere, using their own `Package Keywords' or some such. Or they can just learn to get along with others at the same `Keywords' party. (There have already been attempts to give `Version' a new, restricted interpretation. Fortunately, so far such restrictions apply only to use by package.el, and not to some general redefinition of what `Version' might be for.) > Somebody could estimate it based on Melpa git history. Waste of time, IMO. And likely to misguide.