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: :file keyword for Customize Date: Thu, 8 May 2008 14:34:15 -0700 Message-ID: <001701c8b153$4432c900$0ab32382@us.oracle.com> References: <004101c8b129$788cd490$0ab32382@us.oracle.com> <85zlr0msi8.fsf@lola.goethe.zz> 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 1210282681 12664 80.91.229.12 (8 May 2008 21:38:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 8 May 2008 21:38:01 +0000 (UTC) Cc: 'Emacs-Devel' To: "'David Kastrup'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 08 23:38:35 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 1JuDlj-0000nw-P6 for ged-emacs-devel@m.gmane.org; Thu, 08 May 2008 23:35:16 +0200 Original-Received: from localhost ([127.0.0.1]:59350 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JuDl1-0007x9-DM for ged-emacs-devel@m.gmane.org; Thu, 08 May 2008 17:34:31 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JuDkx-0007wr-6S for emacs-devel@gnu.org; Thu, 08 May 2008 17:34:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JuDkv-0007wJ-MA for emacs-devel@gnu.org; Thu, 08 May 2008 17:34:26 -0400 Original-Received: from [199.232.76.173] (port=42033 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JuDkv-0007wF-F2 for emacs-devel@gnu.org; Thu, 08 May 2008 17:34:25 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]:61673) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JuDkq-0003eo-AX; Thu, 08 May 2008 17:34:20 -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 m48LYGOD032039; Thu, 8 May 2008 15:34:17 -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 m48I0bpi028576; Thu, 8 May 2008 15:34:15 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3669041251210282450; Thu, 08 May 2008 14:34:10 -0700 Original-Received: from dradamslap1 (/130.35.179.10) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 May 2008 14:34:09 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <85zlr0msi8.fsf@lola.goethe.zz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcixTTuQk/JrvfGEQquBILQtBvoNDQAALIoA 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:96825 Archived-At: > > This could provide a little more modularity for packages > > (and for any other groupings of options & faces). > > I don't see what scattering the saved options across > different files has to do with modularity. Scattering is not about modularity, but no one suggested scattering. Grouping is about modularity, and this is about grouping: deciding which options belong together wrt persistence and loading. The choice is not a binary one: (1) accept one giant lump or (2) explode and scatter everything into elementary particles. It's about providing constructs that let programmers and users decide how to group things for persistence and loading: which things to save in the same file. > > It could help deal with things like platform differences (for a > > package) and initialization order of settings. > > Uh no. It actually _curbs_ being able to deal with platform > differences How so? > since you can no longer have one options file per platform. Why not? How would that be prevented? How can adding choices prevent you from doing what you do today? > > 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). > > So what? What is the problem you are trying to fix here? I already said that I don't have a particular problem I am trying to fix. Currently, all user settings are stored persistently in the same sack (modulo special programming to store data in particular files). That's not very modular, and it gives both the programmer and the user little choice wrt what is stored where and when things are loaded - all Customize settings are stored together and loaded together. > > It could simplify communication with package authors about bugs > > (e.g. automatically include the package's Customize > > settings in a bug report). > > Nonsense. report.el already provides a way to report > relevant settings. That report.el exists does not imply that the proposed feature is nonsense. Such reasoning is, however, nonsense. > And if you wanted to have a special way to report everything > customized for a package, you'd do it by listing the customization > group rather than some file. Not necessarily. Customization groups can have many different meanings and different grouping criteria. Those don't necessarily map directly to appropriate persistence and loading models. > We _never_ include a file in bug reports but rather settings. I'll let you speak for what "we _never_" do, but I, for one, have sometimes been interested to see what a user's .emacs or `custom-file' looked like in connection with a bug report. Seeing dynamic settings and seeing persistent values (and knowing when those are loaded) both can sometimes provide useful information. They are not exclusive options. You seem to be bent on imposing non-existent binary choices. There is, in any case, nothing in what I proposed that requires you ("we") to use the feature to communicate persistent settings in bug reports. > And since people could put their settings anywhere, and since > variables can be set without customizing them or even > overriden, a file would be utterly unreliable, anyway, as a > source of information. Again, nothing forces you to "rely" on persistent settings. But there is more than one request in the help lists to see what might be in a reporting user's .emacs - sometimes that's useful. If such information is not useful in some context, or if you think it is "_never_" interesting to you, then, uh, just don't use it; don't ask for it. I would like to be able to (be _able_ to, not be forced to) suggest to a user to load the customizations for package foo after, not before, those for package bar. That is not possible today, when it comes to Customize settings - they're simply all lumped together. > > 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. > > So what? It is a "monolithic blob" not intended for human > consumption, It's certainly intended for programmatic use. And ultimately for human use, in terms of its effects. Such an argument could be applied to all software engineering (and sometimes was, about 40 years ago): just throw everything in one sack; it's all internal, so it doesn't matter how messy it is. > and one can't really delay loading it, anyway. So all this buys us is > added complication and longer load times. No idea what you mean by that. Users today can decide when to load `custom-file'. They could do the same with any such files of Customize options, the same way. > Don't fix what is not broken. Not every improvement is a bug fix.