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: A fundamental problem with defcustoms that are lists Date: Sat, 6 Sep 2008 11:40:10 -0700 Message-ID: <001901c9104f$fe082fe0$0200a8c0@us.oracle.com> References: <48C2BF2F.9040700@gmail.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 1220726429 6909 80.91.229.12 (6 Sep 2008 18:40:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Sep 2008 18:40:29 +0000 (UTC) To: "'Lennart Borgman \(gmail\)'" , "'Emacs Devel'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 06 20:41:24 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 1Kc2ii-0003zZ-8F for ged-emacs-devel@m.gmane.org; Sat, 06 Sep 2008 20:41:16 +0200 Original-Received: from localhost ([127.0.0.1]:57529 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kc2hi-0000St-Hm for ged-emacs-devel@m.gmane.org; Sat, 06 Sep 2008 14:40:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kc2hf-0000So-0e for emacs-devel@gnu.org; Sat, 06 Sep 2008 14:40:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kc2hd-0000SY-9p for emacs-devel@gnu.org; Sat, 06 Sep 2008 14:40:10 -0400 Original-Received: from [199.232.76.173] (port=52991 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kc2hd-0000ST-7a for emacs-devel@gnu.org; Sat, 06 Sep 2008 14:40:09 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]:35894) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kc2hc-0005oX-Mk for emacs-devel@gnu.org; Sat, 06 Sep 2008 14:40:08 -0400 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m86Ie3Ic027743; Sat, 6 Sep 2008 13:40:04 -0500 Original-Received: from acsmt705.oracle.com (acsmt705.oracle.com [141.146.40.83]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id m86Ie2ne010630; Sat, 6 Sep 2008 12:40:03 -0600 Original-Received: from dradamslap1 (/24.23.165.218) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 06 Sep 2008 11:40:02 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <48C2BF2F.9040700@gmail.com> Thread-Index: AckQR4Zh2JmMHuI5R5aO+77XHYnJ2wAAF2jg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 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:103597 Archived-At: > If you have a defcustom which uses variable length lists > (defcustom my-option > :type '(repeat ...)) > > then you may want the default values from the list but also > add some of your own. > > If you customize such an option and the default values are changed you > will not notice because when your setting is used Emacs never sees the > changes in default. > > This mean that any enhancements or bug corrections to the default will > never be used. > > Wouldn't it be worthwhile to give some way to add entries at the > begining or end of the list but add those to the default value instead > of just replacing the default value? A clear recipe would have helped, but I think I know what you mean. I'd say no. The default value of a list option is typically not just a starting point to add to but is a default value to replace. What you raise is the difference between a default value that is a list and a list that includes a minimum set of values by default, that is, a list of default values. In the latter case, a library can do something like this: (defvar foo-defaults '(a b c) "List of default values") (defcustom foo-extras () "Your added values" :type '(repeat ...)) (setq foo (append foo-defaults foo-extras)) You would then customize only `foo-extras' in your scenario, and any update to `foo-defaults' would be accommodated automatically. This is the way to express that a user's changes are limited to additions to a list of default values, not replacement of that list (as a single default value). And `foo-defaults' could itself be a defcustom if we want to let users define the list of default values for `foo'. The difference between the (purposes/uses of the) two options should be made clear to users. In short, if you don't want to lose something, start with nil. "When you ain't got nothin, you got nothin to lose." ;-) I think what you're asking for is that all list options `foo' automatically provide a way to customize only the "extras" part. I think such a possibility should be explicitly provided by the library itself, and only when appropriate. It is only the library that really knows what "default" means and whether it makes sense for users to typically include the defaults and only add to them. The problem you raise is not fundamentally different if a non-list defcustom is used. Any existing user customizations will not take into account a change in the default value for a new version of the library. And that default-value change might well mean that a user would want to change (or remove) an existing customized value. I think there is no magic solution to this potential gotcha - it's what default values are all about. Library changes that are likely to make users want to rethink their customizations are similar to incompatible changes. Even when not truly incompatible, users should be made aware of them. This can be pointed out in the library's doc or even by a runtime or customize-time message. Only the particular library can know whether a particular option or particular code change needs to be treated this way.