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:27:10 -0700 Message-ID: <001501c8b152$46d778a0$0ab32382@us.oracle.com> References: <004101c8b129$788cd490$0ab32382@us.oracle.com><48232D95.3020304@gnu.org><004501c8b12c$d10ce620$0ab32382@us.oracle.com><48233394.5060205@gnu.org> <86d4nwr8vs.fsf@lifelogs.com><000101c8b135$6d360920$0ab32382@us.oracle.com> <868wykr4o3.fsf@lifelogs.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 1210282282 11306 80.91.229.12 (8 May 2008 21:31:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 8 May 2008 21:31:22 +0000 (UTC) To: "'Ted Zlatanov'" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 08 23:31:57 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 1JuDga-0006cC-K5 for ged-emacs-devel@m.gmane.org; Thu, 08 May 2008 23:29:57 +0200 Original-Received: from localhost ([127.0.0.1]:39022 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JuDfs-0005FE-7r for ged-emacs-devel@m.gmane.org; Thu, 08 May 2008 17:29:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JuDf5-0004dZ-28 for emacs-devel@gnu.org; Thu, 08 May 2008 17:28:23 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JuDf3-0004cw-06 for emacs-devel@gnu.org; Thu, 08 May 2008 17:28:22 -0400 Original-Received: from [199.232.76.173] (port=58185 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JuDf2-0004cm-Q6 for emacs-devel@gnu.org; Thu, 08 May 2008 17:28:20 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]:55337) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JuDf1-0002DR-TP for emacs-devel@gnu.org; Thu, 08 May 2008 17:28:20 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m48LSHv6006344; Thu, 8 May 2008 16:28:17 -0500 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m473h9b0001496; Thu, 8 May 2008 15:28:17 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3668630311210282025; Thu, 08 May 2008 14:27:05 -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:27:04 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <868wykr4o3.fsf@lifelogs.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcixPxOabAbkDhbmSDmAT0QxhKDvQQACTRrA 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:96822 Archived-At: > >> FWIW, I would make custom-file accept an alist of > >> defgroup/defcustom symbol name regex, associated with > >> a file name or a function. > > DA> I don't think that's the place to specify such organization, > > We disagree then. Nothing wrong with that. ;-) > DA> and I don't think a regexp offers the right kind of flexibility. > > That may be, the selection mechanism is not important. It > can be a cond form. The point is to put the choice in the user's hands. The ultimate choice must be the user's. But the programmer can write code that decides _how_ users make the choices and _which_ choices they can make. The programmer knows about code dependencies and other internal needs, and can DTRT wrt both the code and the user (UI design) - giving the user the choices s?he needs but guiding how those choices are made. > >> That puts the power in the user's hands, yet allows package authors > >> to add to the alist. The big win is that no special :file > >> keyword is needed, and all existing packages will work with or > >> without this special settings. > > DA> I don't see any such big win. It's no big deal to add a :file > DA> keyword. And all existing packages would continue to work with no > DA> changes - :file would be optional, of course. > > All existing packages can work with the new mechanism I > proposed without modifications, whereas your proposal requires > special *new* code everywhere a different custom file is desired, > and leaves the choice up to whoever writes the source code. > Thus the win is that less code is written all around, users have > more choice, and everything works as it did before. > > DA> This is about letting an individual option or face (or perhaps > DA> group) decide where it is stored (and consequently let > DA> users decide when it is loaded). The place to do that is in > DA> `defcustom' and `defface' (and perhaps `defgroup'). > > I think I understand your proposal, and I think it puts the option in > the place where it's hardest to change it if the package author or the > user should need to do it. It also makes it hard to organize > configurations in a way that the *user* likes. Perhaps I > misunderstand your proposal. Will the user be able to change the > :file parameter on their own without modifying code, for example? What I was thinking was that library writers would typically provide one or more user options or functions as the :file sexps - it is those sexps that would then let users, in effect, determine the :file values used. IOW, end users would not directly determine the sexps used for :file, but they would ultimately determine the values of those sexps in some way (defined by the programmer). There would be nothing in the nature of :file itself that would force programmers to do that, but they would do it naturally - it would make no sense, for instance, for a programmer to hard-code an absolute file name as a :file sexp or it's value. (In that, the example I gave was misleading, but I wanted to get the general idea across, showing that arbitrary code could be used for :file.) The idea would be to let programmers define the choices that an end user has, just as they do with `defcustom' in general (not every variable is a user option). For instance, the code used for several :file args could be made to return the same value in some context if that is appropriate, effectively ensuring that those options would all be stored in the same file. That's different from letting users specify the files to use for individual options arbitrarily. (Of course, any user can always resort to changing the code, as well, but that's not your point nor mine.) > What happens if the file name changes with a new package? Do you add > extra code to handle the possible values of :file? Again, :file would not have a literal absolute file name as argument - no one would code that way. > What if the user wants to save the configuration for two > packages in one custom file, but all other packages in the > default place? That would certainly be possible if each package provided the user a choice wrt the location, as I imagine. The question is how to provide the user with such choices - where to do that. In what I imagine, programmers can do that as they like, using whatever code they think is appropriate as the various :file sexps. They can choose to make these 4 options use the same sexp and those 3 options use a different sexp (regardless of the whether the sexp values differ). They can choose to specify :file at the `defgroup' level and define :group's that fit the persistencs and loading needs. They can do just about anything they think is appropriate for their users. In designing this, the choice is not programmer vs user. The idea is to come up with something for programmers that helps them help their users. Each has some say in defining the persistence and load behavior. It's `and', not `either...or'. > This really is not an unusual need. I like to keep my Gnus and BBDB > variables separate from the rest of Emacs but in one file, for example. > > The default path the package author picks may not be appropriate. > For example, in Gnus a lot of work had to be done to remove > dependencies on ~/News and ~/Mail that were put in place over time. > Many users needed those paths relocated to somewhere that made sense > to them. I don't disagree at all about any of that. The question is which tools to provide programmers so they can meet user needs flexibly.