RE: Honoring traditional defaults [was: Transient Mark Mode on bydefault]

[Drew Adams]

> 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.

Interesting. I first (mis)read that to mean newbies who just wanted to use Emacs
(at least at first) in a way they were used to. IOW, I read the opposite of what
you meant. By "revert to tradition", I at first thought you meant a newbie's
idea of tradition, i.e. what s?he was used to.

Then I read on, and saw what you really meant.

It's interesting (and a bit ironic), because the same approach you propose for
Emacs traditionalists to turn back the clock to a prior Emacs release (Please
just make it work like before!) could also be used to provide alternative
out-of-the-box experiences for Emacs newbies (and others).

That is, provide one or more predefined sets of preference settings. Instead of
the only customization possibility being to dive into the tangled swamp of
Emacs's myriad options, users could choose a suitable macro-level option: a set
of option settings.

The individual low-level options already exist, and a suitable way (e.g. Options
submenu) for users to choose a set of settings could easily be designed. The
hard part might be agreeing on which such sets to provide. But assuming we could
do that without too much trouble, I think it would be a good idea.

Users could then choose among a few predefined Emacs "skins" (though it's more
than skin deep) in, say, the Options menu. Each skin would make a bunch of
settings, such as CUA selection mode, show/hide menus, toolbars, tooltips,...,
whatever. Things that we think newbies might appreciate. And oldbies: Sets that
correspond to the default Emacs behavior for previous releases (what you
described) could be included.

With the possibility of providing more than one skin, just which settings to use
for each skin would be less of a big deal (fight). One of the available skins
would be chosen as the default Emacs behavior. For now, at least, that default
would have the default settings that Emacs already has.

This would provide users with an easy rough cut, to let them quickly get
something more or less suitable. Later, they could fine-tune preferences, like
we all do. This could (1) give users a coarse-grain way to customize, (2)
substitute for some of the here-newbie-start-with-my-dot-emacs that goes around,
and perhaps (3) reduce some of the haggling here over what is TRT to start out
with.

The first task would be to create the infrastructure - something along the lines
of what Stephen proposed. The second task would be to create the UI for choosing
such a set (skin). The third task would be to decide on which sets of which
settings to predefine. The tasks could be done in parallel, if we were sure to
do all three.

It would of course be possible for Lispy users and programs to extend the set of
skins. Color themes are analogous (and a color theme could be a skin component).

WDOT?

> 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.