Honoring traditional defaults [was: Transient Mark Mode on by default]

["Stephen J. Turnbull" <stephen@xemacs.org>]

The only reason not to make Windows/Mac-like behavior the default that
makes sense to me is if we think that traditional Emacs behavior is
*clearly* superior for *most* beginners, enough to make it worth a
short period of confusion and annoyance while they learn to use the
Emacs behaviors.  For something as controversial (and deservedly so)
as t-m-m, I think trying the change at this stage in the release cycle
is a good idea.

On the other hand, the "everything I need to know about Emacs I
learned in kindergarten" crowd *should* have a "revert to tradition"
customization available.  Something like an alist of prior defaults
for customizable variables, having the form ((VAR (VERSION
PRIOR-DEFAULT) ...) ...), where VAR is the symbol naming a
customizable variable, VERSION is a version string identifying a point
of change, and PRIOR-DEFAULT the previous default value.

Then there would be a command `custom-set-all-to-prior-defaults' or
so, which would get a version from the user, defaulting to the prior
public release.  Next, map over the alist of defaults accumulating the
most recent default prior to the user-specified version, if any.  Call
this the "prior defaults alist".  Now the command maps over the prior
defaults alist.  If a variable appears as a key in the prior defaults
alist, and the user has a customization, we ignore it, and continue
with the next variable.  If the user has no customization for the
variable, then we create one, setting the user's customization to the
prior default.

Finally, it emits a warning telling the user which variables it
customized.

If desired, there could also be a customizable variable for
determining how far back to turn the clock, something like
`emacs-version-for-prior-defaults'.  Presumably Alan would set this to
"18.59" or so<wink>.  This would be used instead of the "most recent
public release" as the default for `custom-set-all-to-prior-defaults'.

IMO this handles changes in defaults with a minimum of annoyance to
those with a classical education while making it possible to change
defaults to something more friendly to the GUI generation.

To be honest, I'm not interested in implementing this scheme at this
time, but if and when I get around to it, I'll post here.  If somebody
decides to grab the ball and run with it, I'd appreciate the courtesy
of an email, though.