From xemacs-m  Fri Mar 28 15:23:09 1997
Received: from jens.metrix.de (jens@jens.metrix.de [194.123.88.124])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id PAA26288
	for <xemacs-beta@xemacs.org>; Fri, 28 Mar 1997 15:23:06 -0600 (CST)
Received: (from jens@localhost) by jens.metrix.de (8.7.6/8.7.3) id WAA00480; Fri, 28 Mar 1997 22:22:26 +0100
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: migrating from .xemacs-options to customize
References: <199703280336.UAA20369@branagh.ta52.lanl.gov> <rjiv2c5pnv.fsf@zuse.dina.kvl.dk> <rvybb74xee.fsf@sdnp5.ucsd.edu>
X-Face: Z[@OB)("ZvE?ev~1b+b!0ZUB.$%rh.9qE>dVf>q}Q/V?%d`J3gd!LR\aAZ8<Hwi]xTA(:*c;i3,?K?+rCy*^b$)a,}E?eo},}x2]5LlJysyoUOK"o[>K)'\Ulb7y-7*.If^;rHl['oa)n_M7E6w+LDKMs"G8_`c)uOS1^}.1|8Ill]7X68X-paeUOpBhz<F`B0?~^2Et~GYfw~/0]H]nx4~C_E/_mp#^7Ixc:
Reply-To: jens@lemming0.lem.uni-karlsruhe.de
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
From: Jens Lautenbacher <jens@metrix.de>
Date: 28 Mar 1997 22:22:25 +0100
In-Reply-To: David Moore's message of 28 Mar 1997 11:41:29 -0800
Message-ID: <m367ybn23y.fsf@jens.metrix.de>
Lines: 73
X-Mailer: Gnus v5.4.37/XEmacs 20.1(beta10)

David Moore <dmoore@UCSD.EDU> writes:

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
> 
> [ edit-faces & customize ]
> 
> > You should also be able to use both, if you want.  Edit faces was
> > modified to not save faces that have been saved with customize, and
> > faces declared with custom will not touch a face that is already set.
> 
> I haven't used edit-faces, so I probably don't know all of the issues.
> But I _do_ think it would be good if there was a way to convert the old
> .xemacs-options file to be in customize format.


I believe I have to throw my 0.02 DM in here, too, as I'm the one who
initially started all this confusion by pushing the fade out of
edit-faces when custom seemed to be stable enough to do the job of
customization of faces better then the former.

While it was always a big problem for me that the founder of custom
itself didn't like the change we made, I still think that the decision 
was right in the long term. And despite of what John says, I think
anyone in this discussion on this list should at least be
interested in the reasons _why_  edit-faces is broken and what
consequences this brokenness will have in terms of user-irritation as
more and more people use more than one font family and more than one
font size. 

Yes, I would like to have a conversion program, too. I _can_ see that
it's not funny to wade again through all faces and change them
according to a spec one had already achieved. 

But as this conversion program doesn't exist and I don't know anyone
who would write it, there is of course still the possibility to put
the face specs in a separate file and load this in your .emacs. But
setting options-save-faces to t would of course make the whole
transition useless (as there would be no transition).

Nevertheless the situation isn't perfect either.  I see the following
_real_ problems which I hope can be fixed in the near future:

1) Save options doesn't save _any_ face options now. I would propose
   the following: All options you can select in the options menu like
   font, size, weight should be applied via the same mechanism custom
   uses to the 'default face. "Save Options" in turn should just save
   the customization regarding this special face - 'default - like
   custom would save them. 

2) Thinking about this it comes easily to my mind, that maybe *all*
   options in the options menu should be changed the same way. So we
   would get completely rid of the options file. Seeing it this way,
   the entries in the options menu would just be custom entries in a
   special place and with a special way to set them: Just via the
   menu, no customization buffer is involved.

3) When thinking about this, I finally ask myself: Why do we have nice 
   menu radio buttons in the custom menu for boolean values when
   everything you get when selecting this entry is still a normal
   customization buffer? Why not treat all boolean custom values as
   toggles which _can_ be toggled directly from the menu entry. All
   the relevant calls to custom functions would be made in the
   background.  "Save Options" would be a general safe function that
   would safe all of these options into custom's safe file.

Please, consider this a _proposal_ but nevertheless a doable way of
integrating all the customization stuff we already have under one
package, which seems to be a reasonable way to go in the long term
IMHO


Regards,
	jtl

