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 12:56:35 -0700 Message-ID: <000001c9105a$ab50a560$0200a8c0@us.oracle.com> References: <48C2BF2F.9040700@gmail.com> <001901c9104f$fe082fe0$0200a8c0@us.oracle.com> <48C2D31A.1000804@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 1220731023 21970 80.91.229.12 (6 Sep 2008 19:57:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Sep 2008 19:57:03 +0000 (UTC) Cc: 'Emacs Devel' To: "'Lennart Borgman \(gmail\)'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 06 21:57:58 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 1Kc3us-0005f4-SC for ged-emacs-devel@m.gmane.org; Sat, 06 Sep 2008 21:57:55 +0200 Original-Received: from localhost ([127.0.0.1]:45400 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kc3tt-0000Gg-BY for ged-emacs-devel@m.gmane.org; Sat, 06 Sep 2008 15:56:53 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kc3to-0000GI-Nl for emacs-devel@gnu.org; Sat, 06 Sep 2008 15:56:48 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kc3to-0000FO-1p for emacs-devel@gnu.org; Sat, 06 Sep 2008 15:56:48 -0400 Original-Received: from [199.232.76.173] (port=51521 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kc3tn-0000FI-Ll for emacs-devel@gnu.org; Sat, 06 Sep 2008 15:56:47 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]:64435) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kc3tj-0007xM-N1 for emacs-devel@gnu.org; Sat, 06 Sep 2008 15:56:47 -0400 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m86JuekK028583; Sat, 6 Sep 2008 13:56:40 -0600 Original-Received: from acsmt704.oracle.com (acsmt704.oracle.com [141.146.40.82]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id m86Jucd2008909; Sat, 6 Sep 2008 13:56:38 -0600 Original-Received: from dradamslap1 (/24.23.165.218) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 06 Sep 2008 12:56:38 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <48C2D31A.1000804@gmail.com> Thread-Index: AckQUt5RYBbodqjXSA+cA7AdXTW0PwAAPNSQ 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:103602 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? > > > The default value of a list option is typically not just a > > starting point to add to but is a default value to replace. > > Why do you think so? That's what a default value is: something you can replace. The question is whether your non-nil value serves as the default value of a list (hence, can be replaced) or is a list of default values to serve as the minimal starting point of some other list. Perhaps two different informal senses of the word "default value" are leading to confusion. If a list always starts out with elements (1 2 3) regardless of your customizations, you might want to call that starting point its "default value", but that is not the sense of "default value" that is implemented by defvar or defcustom. They use "default value" in the sense of the value that is used if you don't replace it with something else. Another way to say it is that you want to customize the list in a way that only adds to what was there, not replace it. That is a different customization mechanism. There are ways for a given library to let you do that, as I pointed out. > There are certainly situation when this is the case, but I can without > doubt point to other where instead the default value is > useful and it is natural to complement it, not replace it. Those sound like cases where a list of default values is called for, not a default value that is a list. We can only judge that on a case-by-case basis - be specific. The question is what you (a library) want/expect users to replace: the whole list or just part of it. If you want some part of it to always be there, then include that part automatically, outside of the user's customization. In that case, start the user-replaceable part off with a default value of nil. But I'm repeating myself. > > 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)) > > I can see your idea (but it should not be handled the way you propose > above, use :set instead). Fine. The exact mechanism used is not important here. I was trying to point out the difference between a list of default values and a list that serves as a default value, and that it is the library and its use of the list that decides which it needs (possibly both). > But that would not give the same flexibility as what I propose. Be specific. > Here is my proposal a bit more concretely expressed: > > - In the values stored for a list (ie type 'repeat) for a defcustom > allow a value 'custom-insert-default to insert the default > value for the 'repeat list. How is that better than having a separate variable (or function) that provides the list of default values, and having the code splice that in where needed? Is it that you are trying to give the user greater control over where the default-values list is spliced in? I really don't see a useful use case for this. Why don't you start by explaining your concrete use case or a problematic situation? Either you will convince people that something "fundamental" is in fact missing, or someone will show you that you can already do what you want. > Is that clear? Of course the UI have to provide functionality > for this too. I don't see a need for such a thing, so far. Maybe someone else does. AFAICT, all that is needed is a single mechanism to provide for a default value. It's up to library developers to use that appropriately. But I don't want to discourage you. I was just trying to help, thinking that you were perhaps a bit confused. Please detail your use case and your proposed solution. I'll keep quiet and let others help.