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: byte-compile-nogroup-warn effectively disabled Date: Sun, 8 Jun 2008 23:46:00 -0700 Message-ID: <001901c8c9fc$7b2960b0$0200a8c0@us.oracle.com> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1212993998 7560 80.91.229.12 (9 Jun 2008 06:46:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Jun 2008 06:46:38 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Stefan Monnier'" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 09 08:47:20 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1K5b9y-0000p5-PS for ged-emacs-devel@m.gmane.org; Mon, 09 Jun 2008 08:47:19 +0200 Original-Received: from localhost ([127.0.0.1]:49379 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K5b9B-0002FW-Be for ged-emacs-devel@m.gmane.org; Mon, 09 Jun 2008 02:46:29 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K5b97-0002FM-Hm for emacs-devel@gnu.org; Mon, 09 Jun 2008 02:46:25 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K5b96-0002EZ-2s for emacs-devel@gnu.org; Mon, 09 Jun 2008 02:46:25 -0400 Original-Received: from [199.232.76.173] (port=57060 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K5b96-0002EW-0A for emacs-devel@gnu.org; Mon, 09 Jun 2008 02:46:24 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]:23879) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K5b8z-0003LZ-Az; Mon, 09 Jun 2008 02:46:18 -0400 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m596kE9m027800; Mon, 9 Jun 2008 00:46:15 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id m594NqiM004010; Mon, 9 Jun 2008 00:46:14 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3688511471212993954; Sun, 08 Jun 2008 23:45:54 -0700 Original-Received: from dradamslap1 (/24.5.171.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 08 Jun 2008 23:45:53 -0700 X-Mailer: Microsoft Office Outlook 11 In-reply-to: Thread-Index: AcjJ1CdSjKGYpEykRyOmana4tmF+eQAJOlcQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:98768 Archived-At: > > effectively defeats the point of that warning, which is to > > make sure that every defcustom and defface specifies the group. > > I know it's your opinion, and I disagree. Even without an > explicit :group, the defcustom will have a proper group > attributed to it > because it will use the last group defined in the file. So, in my > opinion it fixes the warning so that it only occurs in cases where the > lack of the :group really leads to the variable being associated to no > group at all. Sorry, I haven't followed this. But IIUYC, I think it would be a mistake to automatically assign an option or face the group that was last specified before it in the same file. What for? What is gained? Sounds like an invitation for user errors that won't necessarily be noticed right away. It might not be an important error to assign the wrong group, but why encourage that possibility? What do you do when more than one :group is used in the previous defcustom? Do you use the last one in that defcustom? Until now, :group order within a defcustom has had no importance. Or do you use all of the :groups of that defcustom? In Icicles, for instance, I have several groups of options - for minibuffer highlighting, completion behavior, *Completions* display, buffer treatment, key bindings, key completion, matching, and so on. In some csaes, an option belongs to more than one such group. I generally present the options in alphabetic order in the file. There is no reason at all to assume that the next option in the file should have the same group(s) as the previous one. If I forget to add a :group, I would rather see a warning and have no group assigned than to have some inappropriate group (not "a proper group") assigned. I don't see the point of this. Personally, I don't care much one way or the other about the warnings - they are just an extra aid. But automatically assigning groups sounds like asking for (minor) trouble.