From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: RE: Improving browsing and discoverability in the Packages Menu Date: Mon, 20 Apr 2015 18:32:30 +0100 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> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c3fd9487acf005142b5095 X-Trace: ger.gmane.org 1429551173 28742 80.91.229.3 (20 Apr 2015 17:32:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Apr 2015 17:32:53 +0000 (UTC) Cc: Alexis , emacs-devel To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 20 19:32:47 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 1YkFYr-0003Pi-Kh for ged-emacs-devel@m.gmane.org; Mon, 20 Apr 2015 19:32:45 +0200 Original-Received: from localhost ([::1]:54752 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkFYr-0003OT-1H for ged-emacs-devel@m.gmane.org; Mon, 20 Apr 2015 13:32:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53280) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkFYe-0003OJ-QU for emacs-devel@gnu.org; Mon, 20 Apr 2015 13:32:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkFYd-00068h-Pe for emacs-devel@gnu.org; Mon, 20 Apr 2015 13:32:32 -0400 Original-Received: from mail-lb0-x22a.google.com ([2a00:1450:4010:c04::22a]:35950) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkFYd-00068T-HB for emacs-devel@gnu.org; Mon, 20 Apr 2015 13:32:31 -0400 Original-Received: by lbbqq2 with SMTP id qq2so136205976lbb.3 for ; Mon, 20 Apr 2015 10:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ORePsacEdUbPLm/OX4ugEGc58QxVfv3jK1Frh3jBZJM=; b=o/YSeZI1l9agVlFs1Ts9ec35w4HfKqPINKsJ98hakSUzPmggPhP/PpLVS+40mAEvyo 6w/9FKwycgLd4EksrhXlIoxcAMzWaShs2ZOUTbvngK5kv7XbZUVu1IXy8pdD0zQHyHnv chqNtC/WLZXLeU0kY9sYD3qdaBMq6dI5gsH+7fOiswvIy5/sxW6SOlH7JyW69ErLBO5w wmAogKxwLMaCZkFlW/HC/PgDMpRUTBFtdugBR+pY03nFbUcvjul0Ia8diZ8fL3xuv23h /sM4TjWeHd1b+wq6i3p1qXIhEUXXmG8LMbq2hqbYCRItn1u1xOC3NBfiLoLacezoJk6E BwYQ== X-Received: by 10.112.63.165 with SMTP id h5mr16323147lbs.16.1429551150770; Mon, 20 Apr 2015 10:32:30 -0700 (PDT) Original-Received: by 10.25.150.1 with HTTP; Mon, 20 Apr 2015 10:32:30 -0700 (PDT) Original-Received: by 10.25.150.1 with HTTP; Mon, 20 Apr 2015 10:32:30 -0700 (PDT) In-Reply-To: <60cf8797-6524-4bf3-8ff5-b8a74736eff6@default> X-Google-Sender-Auth: v83o5Dqhkf6S4cd-DjQbo96FAWI X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::22a 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:185721 Archived-At: --001a11c3fd9487acf005142b5095 Content-Type: text/plain; charset=UTF-8 > > 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)? 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. All keywords would keep working just the same (even those not on the list). This warning would be the only change here. The intention was to nudge developers towards avoiding useless duplicates. We wouldn't enforce anything. Obviously this list of keywords that don't issue warnings would need to grow with time. Which is the most cumbersome aspect here. Let me clarify, I don't think this idea should be implemented as is. I'm just throwing thoughts out there in the hopes we can converge to something useful. I agree the keywords system should never become restricted, but I do think we need to help developers towards standardising it a little. --001a11c3fd9487acf005142b5095 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> > We would just accept any keyword that doesn't = already have...
>
> "We" is what here, exactly?=C2=A0 Just the use of keywords b= y
> `list-packages' (or other package viewing/filtering code)?

The idea is not to restrict or prevent anything, just recomm= end.
We would extend the list of known finder.el keywords. When the byte compile= r is compiling a package, it could issue a warning if it notices keywords t= hat are not part of the known list.
All keywords would keep working just the same (even those not on the list).= This warning would be the only change here.

The intention was to nudge developers towards avoiding usele= ss duplicates. We wouldn't enforce anything. Obviously this list of key= words that don't issue warnings would need to grow with time. Which is = the most cumbersome aspect here.

Let me clarify, I don't think this idea should be implem= ented as is. I'm just throwing thoughts out there in the hopes we can c= onverge to something useful.
I agree the keywords system should never become restricted, but I do think = we need to help developers towards standardising it a little.

--001a11c3fd9487acf005142b5095--