Customize with emacs -q: saving settings

[Drew Adams]

[I'm using a July build; ignore, if this observation is no longer
pertinent because of more recent changes to Customize.  (GNU
Emacs 22.0.50.1 (i386-msvc-nt5.1.2600) of 2006-07-19 on
BOS-CTHEWLAP2 X server distributor `Microsoft Corp.', version
5.1.2600 configured using `configure --with-msvc (12.00)')]


1. The UI I see in Customize with emacs -q is confusing.  It
still speaks of "save", even for emacs -q:

"Use the setting's State button to set it or save changes in it.
 Saving a change normally works by editing your Emacs init file.
 See Custom file for information on how to save in a different
 file."

However, this is now a lie - there is no global Save button and
no State-menu Save option for emacs -q.  Saving has been purged
from the repertoire of actions, but the instructions still speak
of it.  This is poor UI design - very confusing.  Users,
especially first-time users who have no init file, will not
understand anything about this.  They will simply think that
something important is missing somehow (and they will be right).

I understand why saving was made impossible for emacs -q - but
users will not understand that, unless we tell them.  The doc
and, especially, the UI itself should make this very clear.

The UI should remain the same - same menu items, same buttons,
regardless of whether -q is used.  Any items and buttons that are
deemed inappropriate for emacs -q (or for any other particular
context) should simply be deactivated.  Users must be able to see
the same UI in all contexts. Any UI differences should be the
result of the user doing something different, and they should be
recognizable as such - IOW, the user should recognize that
something has changed and understand why.

The only change to the UI for emacs -q should be an explicit
mention there that for emacs -q saving is deactivated.  This must
be made clear in these terms.


2. However, I personally think it is also poor design not to let
users save settings from an emacs -q session.  The only thing
that needs to be prevented is their saving settings into their
init file or custom file.  The reasonable thing to do would be to
let them save only to a non-existent file, and let them know that
the saved settings will not be used automatically in future Emacs
sessions.

If `custom-file' is not defined and no init file (.emacs) exists,
then .emacs would be the first choice (default) for the file to
save in.  In fact, this should be the recommended (or _a_
recommended) way to create an init file: use Customize to change
and then save settings.

Otherwise, if an init file or custom file already exists, then an
alternative file that doesn't exist would be proposed.  The name
of the alternative file would be derived from the `custom-file'
value, if available, or from .emacs (e.g. .emacs-2), otherwise.

In the case where a user has an init file or `custom-file'
already, s?he would be notified when saving that the settings are
being saved in a file that is not the custom file or init file.
Users will understand from this UI that they can save only to a
new file, which will not then be used as their custom/init file.
They will also still have the option of not saving at all, if
they see no use in saving to another file.  IOW, the current
behavior would be included as an option, not imposed.

Users could later manually merge such saved settings into their
init file or custom file, swap the newly saved file with their
original init file or custom file, or ignore the saved file.  In
case they ignore the file, that is equivalent to not saving,
except that they can change their minds later and use the saved
settings in some way.

I'm also opposed to telling users never to edit what
customization puts in their init files.  What they should be
told, instead, is that changes they make there might be
automatically overwritten by subsequent customizations.