From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: Improving browsing and discoverability in the Packages Menu Date: Tue, 21 Apr 2015 08:52:14 +0200 Message-ID: <87lhhmgeht.fsf@gnu.org> 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> <87zj62unvk.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1429599152 1671 80.91.229.3 (21 Apr 2015 06:52:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Apr 2015 06:52:32 +0000 (UTC) Cc: bruce.connor.am@gmail.com, emacs-devel To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 21 08:52:26 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 1YkS2i-0003tC-Em for ged-emacs-devel@m.gmane.org; Tue, 21 Apr 2015 08:52:24 +0200 Original-Received: from localhost ([::1]:56495 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkS2h-0000Zr-Sr for ged-emacs-devel@m.gmane.org; Tue, 21 Apr 2015 02:52:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55114) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkS2d-0000Wz-Rm for emacs-devel@gnu.org; Tue, 21 Apr 2015 02:52:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkS2a-0001Ky-KN for emacs-devel@gnu.org; Tue, 21 Apr 2015 02:52:19 -0400 Original-Received: from deliver.uni-koblenz.de ([141.26.64.15]:54292) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkS2a-0001Kj-FU for emacs-devel@gnu.org; Tue, 21 Apr 2015 02:52:16 -0400 Original-Received: from thinkpad-t440p (dhcp229.uni-koblenz.de [141.26.71.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id 255341A83EF; Tue, 21 Apr 2015 08:52:15 +0200 (CEST) Mail-Followup-To: Drew Adams , bruce.connor.am@gmail.com, emacs-devel In-Reply-To: (Drew Adams's message of "Mon, 20 Apr 2015 22:25:37 -0700 (PDT)") User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 141.26.64.15 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:185741 Archived-At: Drew Adams writes: >> If it were intended by the package author, where is the problem of >> adding >> ;; byte-compile-warnings: (not unknown-keyword) >> to the package's local variables section? > > So to some file written by someone somewhere somewhen, perhaps quite > some time ago, you say: "All ya gotta do is jump through this leetle > hoop here." Yes, exactly. Because if it is available via ELPA, MELPA, or some other package archive, then it seems to be actively maintained. And in the very unlikely case that the author/maintainer insists on "modeline" instead of "mode-line", she can jump through the little hoop. BTW, an `unknown-keyword' warning was not really what I meant in my previous reply. Of course, package.el cannot know all sensible keywords, so it should work with any keyword. But in the case of keywords that are likely just synonyms or typos of some commonly used keyword (modeline vs. mode-line), it could suggest the commonly used one for achieving a bit standardization. >> And I'm pretty sure you won't see any occurrence of >> ;; Keywords: modeline, electronic mail >> ;; Package Keywords: mode-line, email >> even if there was a new field. > > Sorry, I didn't catch your last point. Perhaps you mean to say that > `Keywords' will disappear? All the kids will run to play in the new > sandbox? No, what I've meant to say is that when a maintainer adds the new `Package Keywords' header duplicating the existing `Keywords' header and then sees that byte-compilation suggests to use the more commonly used "mode-line" and "email" instead of "modeline" and "electronic mail", why should she change only `Package Keywords` accordingly and not `Keywords', too? (Assuming that she agrees that "mode-line" and "email" express what she intended to express, too.) She doesn't know that there are some people that don't want `Keywords' to be changed. Or should the warning say something like that? The Package Keywords entry "modeline" is likely to mean "mode-line". If you agree, change it accordingly but please let the Keywords header as-is for the Olt Town's habitants peace of mind. Bye, Tassilo