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: :file keyword for Customize Date: Thu, 8 May 2008 09:35:04 -0700 Message-ID: <004101c8b129$788cd490$0ab32382@us.oracle.com> 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 1210264571 13219 80.91.229.12 (8 May 2008 16:36:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 8 May 2008 16:36:11 +0000 (UTC) To: "'Emacs-Devel'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 08 18:36:47 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 1Ju96R-0002ce-1Q for ged-emacs-devel@m.gmane.org; Thu, 08 May 2008 18:36:19 +0200 Original-Received: from localhost ([127.0.0.1]:53405 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ju95i-0003Uo-MF for ged-emacs-devel@m.gmane.org; Thu, 08 May 2008 12:35:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ju95c-0003UF-VP for emacs-devel@gnu.org; Thu, 08 May 2008 12:35:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ju95a-0003Tg-Kf for emacs-devel@gnu.org; Thu, 08 May 2008 12:35:27 -0400 Original-Received: from [199.232.76.173] (port=35829 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ju95a-0003Td-CR for emacs-devel@gnu.org; Thu, 08 May 2008 12:35:26 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]:37882) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ju95a-0000wr-0F for emacs-devel@gnu.org; Thu, 08 May 2008 12:35:26 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m48GZFsO028745 for ; Thu, 8 May 2008 10:35:15 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m473El9g007187 for ; Thu, 8 May 2008 10:35:14 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3668554261210264499; Thu, 08 May 2008 09:34:59 -0700 Original-Received: from dradamslap1 (/130.35.179.10) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 May 2008 09:34:58 -0700 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AcixKXgoZQce2MckS9qfkU2X0NXQTA== 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:96799 Archived-At: How about adding a :file keyword for `defcustom' and `defface'? (defcustom foo-bar-flag t "Non-nil means toto." :type 'boolean :group 'foo :file (if (eq system-type 'windows-nt) "C:\\foo-stuff\\foo-cus.el" "/toto/foo-stuff/foo-cus.el")) Its argument would be evaluated to a file name. That particular `defcustom' or `defface' setting would be saved in that file, instead of in `custom-file' or `init-file'. A nil or "" value for :file would mean the same thing as the absence of a :file keyword: as now, use `custom-file' or, if no `custom-file', `init-file'. This could provide a little more modularity for packages (and for any other groupings of options & faces). It could help deal with things like platform differences (for a package) and initialization order of settings. It could allow users a little more flexibility in terms of when some groups of Customize settings are loaded (currently, all Customize settings are loaded at once). It could simplify communication with package authors about bugs (e.g. automatically include the package's Customize settings in a bug report). I don't have a particular use-case in mind; it's just something that occurred to me. There is nothing special in this, but I think it might help organize things a bit. A user's `custom-file' or `init-file' can become a monolithic blob, and this could help cut down on that.