From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dave Love Newsgroups: gmane.emacs.devel Subject: Re: Custom dependencies (was: utf-translate-cjk-mode) Date: 08 Apr 2003 10:34:28 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <8465pvpnhy.fsf@lucy.is.informatik.uni-duisburg.de> <200304041519.h34FJa9n007445@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1049794589 1035 80.91.224.249 (8 Apr 2003 09:36:29 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 8 Apr 2003 09:36:29 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Apr 08 11:36:27 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 192pWl-0000GY-00 for ; Tue, 08 Apr 2003 11:36:27 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 192pah-0003ap-00 for ; Tue, 08 Apr 2003 11:40:31 +0200 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 192pW8-0004LW-04 for emacs-devel@quimby.gnus.org; Tue, 08 Apr 2003 05:35:48 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 192pVY-0003QN-00 for emacs-devel@gnu.org; Tue, 08 Apr 2003 05:35:13 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 192pV4-0002JA-00 for emacs-devel@gnu.org; Tue, 08 Apr 2003 05:34:43 -0400 Original-Received: from albion.dl.ac.uk ([148.79.80.39]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 192pUs-00021c-00 for emacs-devel@gnu.org; Tue, 08 Apr 2003 05:34:30 -0400 Original-Received: from fx by albion.dl.ac.uk with local (Exim 3.36 #1 (Debian)) id 192pUq-0002yZ-00; Tue, 08 Apr 2003 10:34:28 +0100 Original-To: "Stefan Monnier" Original-Lines: 75 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:13021 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13021 "Stefan Monnier" writes: > [ Since the :set-after thingy is now (hopefully) finally properly > handled by define-minor-mode, I assume that you now agree that Kai's > change was good. ] Sure (but not the rationale). > I think the issue of dependencies is important, so let's try and improve > it, rather than keep working around it. Is there much attempt to work around it? > Especially since you > mention that it is crucial in order to customize calendar properly. I think it's only really important if the current system of options is maintained, but I don't know how much trouble it would cause to change the currently-defined options. The problem there is the multiple levels of customized options, such that if I want to default things appropriate to the locale, it's a real mess in ways I can't remember the details of. > - The case as above where variable A has a non-trivial :set function > which depends on variable B, so that when B is changed something > should be done to A. > It seems that the :set-after thingy is a good way to specify the > dependency, but it doesn't describe what should be done to A > when B changes. I think it does. A should be re-set from its current value, since something it depends on has changed. Are there cases in which that would be wrong? > Kai suggests turn A off and back on, but you > seem object to it. I don't remember that, and it's not anything I thought I was objecting to. It's not a question of off and on in this case anyhow -- the state that changes is the contents of a hash table. > I believe that you object only to > set-language-environment doing it, not to the off&on thing: it > should be done by custom without set-language-environment > (or current-language-environment for that matter) knowing anything > about utf-translate-cjk-mode. Yes, if I understand correctly. > - The case where A is set to "the value of E" where E is a sexp > that refers to B. In such a case, the dependency is not part of > A but of A's current setting, so :set-after is not a good solution. That's strictly true, but in most cases I can think of, it is the right thing. You'd have :set-after's for the Custom options which are `usually' involved in E -- not strictly right, but unlikely to cause trouble, I guess. This probably means that the customization of those options isn't done the way it should be, i.e. A shouldn't really be set with `defcustom' but in some new way which is also aware of Custom's dependency information. (I haven't thought very much about implementing such a thing, but I've often run into this issue.) Take `display-time-string-forms' as an example that I recently worked on (rather surprised that people could live with the distraction in the new about-face mode line). It's unlikely that a naive Custom user would want to mess with the sexp as such, and probably unlikely that anyone would unless they were adding new options. I'd expect them just to set `display-time-use-mail-icon' &c. If `display-time-string-forms' was re-set when `display-time-use-mail-icon' & al were set, it would be less confusing for users and the mode-line update could be more efficient. Does that make sense?