From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Compilation warnings in mouse.el Date: Wed, 13 Jul 2016 08:45:34 -0400 Message-ID: References: <87bn21nayo.fsf@fastmail.fm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1468413985 11255 80.91.229.3 (13 Jul 2016 12:46:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Jul 2016 12:46:25 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 13 14:46:18 2016 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 1bNJYP-0003M0-OT for ged-emacs-devel@m.gmane.org; Wed, 13 Jul 2016 14:46:17 +0200 Original-Received: from localhost ([::1]:47193 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNJYP-00049r-0u for ged-emacs-devel@m.gmane.org; Wed, 13 Jul 2016 08:46:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40913) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNJXt-00049l-Uj for emacs-devel@gnu.org; Wed, 13 Jul 2016 08:45:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bNJXq-0002xo-Ne for emacs-devel@gnu.org; Wed, 13 Jul 2016 08:45:45 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:40518) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNJXq-0002xj-Cf for emacs-devel@gnu.org; Wed, 13 Jul 2016 08:45:42 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1bNJXo-0002zY-Jw for emacs-devel@gnu.org; Wed, 13 Jul 2016 14:45:40 +0200 Original-Received: from 69-165-156-121.dsl.teksavvy.com ([69.165.156.121]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Jul 2016 14:45:40 +0200 Original-Received: from monnier by 69-165-156-121.dsl.teksavvy.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Jul 2016 14:45:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 32 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 69-165-156-121.dsl.teksavvy.com User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cancel-Lock: sha1:rj8seEtV+eEzEG2JbODjVYRuuvI= 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.21 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" Xref: news.gmane.org gmane.emacs.devel:205618 Archived-At: EZ> Unlike Stefan, I think we should add :group to every defcustom. Having EZ> them mysteriously missing from some of them is a time bomb: >> The way I see it, defcustoms should pretty much never have :group, and >> the group to which they belong is simply determined by the file in which >> they occur. > That would mean that in multifile packages the defcustoms must always be > put in one single file, Notice I said "pretty much". Obviously, there will be exceptions, so we do want to keep the :group for those situations. > which must be named according to the customisation group one wants to > create. And creating multiple customisaton groups for a single package > (not uncommon in larger packages) would require multiple files. The current system (default to the last group defined in the current file) lets you define several groups along with their defcustoms in a single file without the use of :group. > That's to say, such a system would require that the code of a package be > organised along the lines of the customisation groups it provides. But > customisation is a UI feature, and as such does not necessarily present > the best way to organise the code. Agreed. But in practice the most common situation is to have the defgroup in the same file as the corresponding defcustoms. Maybe a bit less so in multi-file packages (especially less so in *small* multi-file packages, I think). Stefan