Robert Pluim writes:
Putting them in by default will just annoy people like me who prefer
XEmacs bindings (I know, I can edit init.el, but I don't want anything
touching that file *at all*).
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).
XEmacs-Patches mailing list