From xemacs-m  Tue Apr 15 21:48:16 1997
Received: from wmperry.in.aventail.com (wmperry@wmperry.oz.net [207.13.185.53])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id VAA05853
	for <xemacs-beta@xemacs.org>; Tue, 15 Apr 1997 21:48:14 -0500 (CDT)
Received: (from wmperry@localhost) by wmperry.in.aventail.com (8.7.6/8.7.3) id TAA00517; Tue, 15 Apr 1997 19:46:38 -0700
Sender: wmperry@wmperry.in.aventail.com
To: Per Abrahamsen <abraham@dina.kvl.dk>
Cc: Hrvoje Niksic <hniksic@srce.hr>,
        XEmacs Developers <xemacs-beta@xemacs.org>,
        emacs-custom@sunsite.auc.dk
Subject: Re: Specifiers in custom
References: <kigzpv3xjqu.fsf@jagor.srce.hr> <rj912mj446.fsf@zuse.dina.kvl.dk> <kigiv1qyjyr.fsf@jagor.srce.hr> <rjzpv2ho21.fsf@zuse.dina.kvl.dk> <kigohbgh9t8.fsf@jagor.srce.hr> <rj912kfu45.fsf@zuse.dina.kvl.dk> <kign2r0h6z5.fsf@jagor.srce.hr> <rj67xofpjo.fsf@zuse.dina.kvl.dk>
Errors-to: wmperry@aventail.com
Reply-to: wmperry@aventail.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;
From: wmperry@aventail.com (William M. Perry)
Date: 15 Apr 1997 06:05:03 -0700
In-Reply-To: Per Abrahamsen's message of 15 Apr 1997 14:17:47 +0200
Message-ID: <86pvvwl9mo.fsf@wmperry.in.aventail.com>
Lines: 63
X-Mailer: Gnus v5.4.42/Emacs 19.34

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> > It would work, without a special-case support for specifiers, which
> > you don't like (the specifiers, not the special-case).  Can you
> > propose a nicer implementation?
> 
> The :type argument describes the value, not how to set or get it.
> Doing what you outlined would be a violation of the layers.
> 
> However, your basic point is right.  Sorry for just giving a knee-jerk
> reaction to the layer violation, instead of looking further.  The only
> difference is that the keywords will apply directly to the defcustom, not
> to the type argument, like this:
> 
> (defcustom ispell-dictionary nil
>   "bla bla"
>   :type '(choice (const :tag "default" nil)
>                  (string :format "%v"))
>   :group 'ispell
>   :set (lambda (symbol value)
>          (if (featurep 'ispell)
>              ;; Ispell is not loaded yet, just setting the variable will work!
>              (set-default symbol value)
>            ;; After loading the library, we must call this function.
>            (ispell-change-dictionary value))))

  This will be great for 'meta-variables' that usually require a function
to be invoked to alter other variables that depend upon it.
url-privacy-level is one I can think of off the top of my head, and I
believe gnus has a few as well.

> - How should other namespaces be handled?  `ispell-dictionary' lives
>   in the variable namespace, but I can easily think of examples of
>   customizations that aren't directly associated with variables.
>   Specifiers may be one of these.  Forcing them into the variable
>   namespace seems wrong.

  Well, specifiers are really just variables that have taken a heavy hit of
LSD, followed by an even heavier hit of jolt cola. :)  If such
functionality were available though, you could easily get rid of such
meta-variables, if you wanted.  Not sure if relying on custom for that is a
good or bad thing though... some people might still want to change it by
hand.

> - How about initialization?  If the user saves an option with a :set
>   or :get argument, should the file with the defcustom then be loaded at
>   upstart to get at them?  Or should the get/set functions be saved in
>   the users .emacs file?

  Hmmmm... not sure about that one.  That's where it would be nice to say
'all w3 customizations go in ~/.w3/profile', since W3 will be already
loaded when that file is read in.  Perhaps a new :file (better naming
welcome) attribute on a group that would specify a file to save the
resulting customizations in?  Defaulting to user-init-file of course.  Not
sure how this would work with items in multiple groups.

-Bill P.
-- 
William Perry			wmperry@aventail.com
Unix Server Development Lead  & Emacs-W3 Author
Aventail, Corp.			http://www.aventail.com

