Robert Pluim writes: About the letter of what you've written, I think about ten people will veto any attempt to write anything into init.el or custom.el. Regarding the spirit, wasn't it Mark Twain who said, "Always do right, it will gratify some people and astonish the rest"? I see a half- baked parallel to "Fix the defaults, it will cause your application to be unnoticed by most people and annoy the rest". The thing is, if we do this dastardly deed, you and Aidan (I'm thinking of his autodetect mixed-mode use suggestion) will have to fix your configurations once (and to the extent it's ./configure-time stuff you might have to write a script or .BAT file). If we don't do it, real Windows and Mac users that (in theory) we could attract to XEmacs just plain won't ever warm up to XEmacs. I kinda think that latter is more important. What we really need to keep the burden on you bearable is a way to create custom themes that would reset everything to the old defaults. This could be based on a per-defcustom :default-changed-version keyword, a per-defcustom :previous-defaults-alist keyword, and a user variable `user-defaults-version'. Then when you upgrade, you are presented with a notification that your user-defaults-version is older than the current one, and that defaults have changed. You'd get three options: accept all new defaults (do nothing), customize changed (which would give a customize-group-like list of all the defcustoms whose defaults have changed since your user-defaults-version), or keep old defaults (in which case XEmacs would automatically customize those variables whose defaults have changed to the most recent default prior to your user-defaults-version in the :previous-defaults-alist). WDOT? _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches