From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: Improving browsing and discoverability in the Packages Menu Date: Mon, 20 Apr 2015 22:03:45 +0800 Message-ID: <87wq16c2wu.fsf@ericabrahamsen.net> 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 X-Trace: ger.gmane.org 1429538678 31614 80.91.229.3 (20 Apr 2015 14:04:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Apr 2015 14:04:38 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 20 16:04:29 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 1YkCJI-0005CX-O1 for ged-emacs-devel@m.gmane.org; Mon, 20 Apr 2015 16:04:28 +0200 Original-Received: from localhost ([::1]:53665 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkCJC-0003YR-T7 for ged-emacs-devel@m.gmane.org; Mon, 20 Apr 2015 10:04:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53695) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkCIv-0003YI-59 for emacs-devel@gnu.org; Mon, 20 Apr 2015 10:04:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkCIr-0006J9-UF for emacs-devel@gnu.org; Mon, 20 Apr 2015 10:04:05 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:52672) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkCIr-0006Iy-NW for emacs-devel@gnu.org; Mon, 20 Apr 2015 10:04:01 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YkCIp-0004xh-Eb for emacs-devel@gnu.org; Mon, 20 Apr 2015 16:03:59 +0200 Original-Received: from 222.129.224.131 ([222.129.224.131]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 20 Apr 2015 16:03:59 +0200 Original-Received: from eric by 222.129.224.131 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 20 Apr 2015 16:03:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 41 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 222.129.224.131 User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:GiqqzmucCpx/3jYuXclVVJ2Aq6s= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:185701 Archived-At: Alexis writes: > Artur Malabarba writes: > >>> Maybe just expand the canonical list of curated keywords, then let >>> package authors add their own on top of that? >> >> This by itself will take a very long time, if ever, to have any >> effect. It would have to be coupled with something else. For >> instance, there could be a compiler warning if the package has >> unknown keywords. This wouldn't prevent the keyword from working, >> but it would inform the developer to either change the keyword or >> ask us to add it in. Is that too much? > > Hmm .... i'm not sure how practical that last bit is. For example: > should "vcard" be added as an 'official' keyword? (i currently include > it in the list of keywords for `org-vcard', the other two being > "outline" and "org".) Should i instead replace the "vcard" keyword > with "contacts", given that people could plausibly find `org-vcard' > via searching package names instead of keywords for the term 'vcard', > but currently wouldn't find it were they thinking in terms of > "contacts management"? Who would be the person or people making the > decision on whether a keyword should be added, modified or removed? > Might such a process result in emacs-devel being flooded with > interminable ontological bikeshedding? The danger is great. I don't have a wonderful solution, either, but I'm seeing a vague vision of some sort of a two-tiered system: the first a limited list of curated categories set by someone in a position of authority, and another free-for-all keyword mashup. In your example, you'd categorize your package as "contacts" under tier one, and put "vcard" and "org" and whatever else in tier two. Package filtering would happen on both tiers, perhaps with completion only for the first tier. I can imagine two different package headers: Category and Keywords, corresponding to the two tiers. I can also imagine tier one coming from Keywords, and tier two coming from searching the Commentary section. That's all I've got. Eric