From xemacs-m  Tue Apr  8 12:35:10 1997
Received: from crystal.WonderWorks.COM (crystal.WonderWorks.com [192.203.206.1])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id MAA04947
	for <xemacs-beta@xemacs.org>; Tue, 8 Apr 1997 12:35:08 -0500 (CDT)
Received: by crystal.WonderWorks.COM 
	id QQckkk27342; Tue, 8 Apr 1997 13:35:04 -0400 (EDT)
Date: Tue, 8 Apr 1997 13:35:04 -0400 (EDT)
Message-Id: <QQckkk27342.199704081735@crystal.WonderWorks.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Kyle Jones <kyle_jones@wonderworks.com>
To: XEmacs Developers <xemacs-beta@xemacs.org>
Subject: Re: minibuf.el
In-Reply-To: <199704081655.MAA13047@anthem.CNRI.Reston.Va.US>
References: <kigbu7phc96.fsf@jagor.srce.hr>
	<QQckka25111.199704081500@crystal.WonderWorks.COM>
	<rj7midselu.fsf@zuse.dina.kvl.dk>
	<QQckke26142.199704081614@crystal.WonderWorks.COM>
	<rj4tdhscaa.fsf@zuse.dina.kvl.dk>
	<199704081655.MAA13047@anthem.CNRI.Reston.Va.US>
X-Mailer: VM 6.24 under 19.15 XEmacs Lucid
X-Face: /cA45WHG7jWq>(O3&Z57Y<"WsX5ddc,4c#w0F*zrV#=M
        0@~@,s;b,aMtR5Sqs"+nU.z^CSFQ9t`z2>W,S,]:[+2^
        Nbf6v4g>!&,7R4Ot4Wg{&tm=WX7P["9%a)_da48-^tGy
        ,qz]Z,Zz\{E.,]'EO+F)@$KtF&V

Barry A. Warsaw writes:
 > 
 > >>>>> "PA" == Per Abrahamsen <abraham@dina.kvl.dk> writes:
 > 
 >     PA> * A variable's documentation string should start with `*' if
 >     PA>   the
 >     PA> variable is one that users would often want to set
 >     PA> interactively.  If the value is a long list, or a function, or
 >     PA> if the variable would be set only in init files, then don't
 >     PA> start the documentation string with `*'.  *Note Defining
 >     PA> Variables::.
 > 
 > I've always interepreted this to mean user customizable.  I don't
 > think the init file distinction makes much sense, and you certainly
 > have to lump customize in with setting interactively.

I agree and I've treated the *'d variable the same way in everything
I've written.  The comment I made about "you'd better know what
you're doing" reflects my perception of reality.  As an example, if
you screw up the minibuffer keymaps, You Will Be Sorry.  If you
change the regexps that VM uses to parse folders, You Will Be
Sorry.  If you redefine `obarray', You Will Be (Very) Sorry.

On the other hand, some of the variables might be harmless to
set.  use-dialog-box, for instance, has no *, but a user might
want to set it interactively.

 > The length distinction just means we need better a UI to set
 > those variables.

I agree.  What I've decided to do with VM's hairball variables
(vm-virtual-folder-alist, vm-auto-folder-alist, and
vm-spool-files come to mind) is write functions to modify them.
The function would have simple call syntax which avoids users
having to write lists of lists of lists of...  There needs to be
another layer on top of even this, but by the time I finish
writing the access/modify functions I'll have a better idea what
that layer ought to be.

