From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier " Newsgroups: gmane.emacs.help Subject: Re: Customize enforcing data relationships? Date: 17 Feb 2003 11:04:03 -0500 Organization: Yale University Sender: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: <5l65ri51xo.fsf@rum.cs.yale.edu> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1045498197 18442 80.91.224.249 (17 Feb 2003 16:09:57 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 17 Feb 2003 16:09:57 +0000 (UTC) Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18knq7-0004nC-00 for ; Mon, 17 Feb 2003 17:09:55 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18knmA-0003fv-04 for gnu-help-gnu-emacs@m.gmane.org; Mon, 17 Feb 2003 11:05:50 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!logbridge.uoregon.edu!news.ycc.yale.edu!rum.cs.yale.edu!rum.cs.yale.edu Original-Newsgroups: gnu.emacs.help Original-Lines: 23 Original-NNTP-Posting-Host: rum.cs.yale.edu User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-Original-NNTP-Posting-Host: rum.cs.yale.edu X-Original-Trace: 17 Feb 2003 11:04:03 -0500, rum.cs.yale.edu Original-Xref: shelby.stanford.edu gnu.emacs.help:110286 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:6790 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:6790 > More thoughts are that, of course, it would be the package developer's > responsibility to define the relationships. He could define through > some custom function, say, "defcustomrel", that B must be set if A is > set. Then customize could see the user set A and immediately jump the > user to B and the setting of A isn't complete until the user has set B, > thus enforcing the dependency. Even better would be displaying them > together as well, with the dependency mapped out visually. The problem is that dependency is typically of the form (defcustom a foo) (defcustom b (bar a)) and people think "Aha! B depends on A", but then some user comes along and changes her setting for B from (bar a) to (baz c) and maybe she even changes A's setting to (foz b) and we now have a completely different dependency. So I don't think the dependency should be specified as part of the `defcustom' but as part of the value instead. Stefan