From xemacs-m  Mon Apr 21 16:52:44 1997
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id QAA00335
	for <xemacs-beta@xemacs.org>; Mon, 21 Apr 1997 16:52:42 -0500 (CDT)
Received: (from hniksic@localhost)
          by jagor.srce.hr (8.8.5/8.8.4)
	  id XAA07334; Mon, 21 Apr 1997 23:52:41 +0200 (MET DST)
To: XEmacs Developers <xemacs-beta@xemacs.org>
Subject: Re: Build Success - 20.2b1 - Linux2.0.28, but...
References: <m2iv1hg0w7.fsf@sauna.ton.tut.fi> 	<m2hgh1obrn.fsf@altair.xemacs.org> 	<QQcmcx22856.199704201851@crystal.WonderWorks.COM> 	<m2iv1hsdau.fsf@sauna.ton.tut.fi> 	<QQcmdo26168.199704202313@crystal.WonderWorks.COM> 	<m2ohb8gj2i.fsf@altair.xemacs.org> <QQcmha22540.199704212138@crystal.WonderWorks.COM>
X-URL: ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/
X-Attribution: Hrv
X-Face: Mie8:rOV<\c/~z{s.X4A{!?vY7{drJ([U]0O=W/<W*SMo/Mv:58:*_y~ki>xDi&N7XG
        KV^$k0m3Oe/)'e%3=$PCR&3ITUXH,cK>]bci&<qQ>Ff%x_>1`T(+M2Gg/fgndU%k*ft
        [(7._6e0n-V%|%'[c|q:;}td$#INd+;?!-V=c8Pqf}3J
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 21 Apr 1997 23:52:40 +0200
In-Reply-To: Kyle Jones's message of Mon, 21 Apr 1997 17:38:11 -0400 (EDT)
Message-ID: <kigrag4cac7.fsf@jagor.srce.hr>
Lines: 55
X-Mailer: Gnus v5.4.45/XEmacs 19.15

Kyle Jones <kyle_jones@wonderworks.com> writes:

>  > O.K.  That makes sense.  How do we fix^H^H^Hput a bandaid on this?
>  > The customize menu is pretty terrifying in all the packages it loads
>  > and requires an unusual amount of dexterity to navigate, could we
>  > remove it for the time being?

I think it would be wise to remove it, as much as I'm attached to
it.  It should probably be only two levels deep, as it is in GNU
Emacs. :-(

> As for the Customize menu, I'm currently of the opinion that all
> the defcustoms should be slurped out of all the bundled packages,
> dropped into a file, and dumped with XEmacs.  Hopefully this
> would get rid of the need to load all that stuff on the fly from
> the menus.

I don't think it's feasible, generally.  Many initial values are not
known until the package is in the phase of loading.  A great number of
packages do thing like this:


(defun foo-blah (buf)
  "Returns non-nil iff the buffer is not bogus."
  ....)

(defcustom foo-bar (foo-blah (current-buffer))
  "Whether the current buffer is considered bogus."
  :type 'boolean
  :group 'foo)
(make-variable-buffer-local 'foo-bar)

In even worse cases, defcustom doesn't even have to call a
package-specific function, but the created value still makes sense
only when loading a package:

(select-frame (make-frame))
...
(defcustom foo-baz (frame-width)
  "The width of BAZ in package FOO.
This default to the width of the FOO frame."
  :type 'integer
  :group 'foo)

While both of these examples are trivial, I think they demonstrate why
it is not a good idea to make `defcustom' anything else but an
extension of `defvar'.  Introducing new requirements would imply
changes in a lot of packages, much more complex than the current
custom changes are.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Thou Who might be our Father Who perhaps may be in Heaven...
                                                -- Roger Zelazny

