RE: [External] : Re: Default custom file was: Re: Propose to add setup-wizard.el to ELPA

[Drew Adams <drew.adams@oracle.com>]

> >> 7. Suppose a longtime user doesn't read the NEWS
> >>    etc., and _does nothing_.  What happens then?
...
> >> c. If the user then makes some custom* changes
> >>    and saves them, they're saved to the default
> >>    `custom-file' location, _not_ to the init file.
> 
> How about ignoring all of that, and asking the user
> where to save his customizations when he tries to
> save them for the first time?
> 
> That seems like the best solution to me.

You don't say _why_ it seems best to you.
So...why?
___

I think I already replied to your how-about
question, but let me elaborate a bit.

If that were to be done, the agreed-on default
location (e.g. ~/emacs-custom.el) should be
presented explicitly (inserted in minibuffer)
for confirming/editing, as opposed to just
being available with `M-n' (which many users,
especially new ones, aren't even aware of).

Even doing that, I'm guessing that more users
might go with their init file than would be the
case with what I proposed: just default to the
default location.

I see 3 levels mentioned so far:

1. What we have now: default is init file, and
   if a user wants a separate `custom-file' she
   has to know about that possibility and go
   through the steps to set it up explicitly.

   This overwhelmingly favors saving to their
   init file, i.e., no separate `custom-file'.

2. What you propose: essentially no change,
   except to prompt for where to save at the
   first customize save.  (First for all time,
   or first for each Emacs session, or what?)

3. Default to the new default (what I proposed).
   Start saving there.  Call it out in doc & NEWS.

   This favors users changing to a separate
   `custom-file'.  They have to explicitly go to
   the trouble of customizing that var to their
   init file (or perhaps to nil), to use their
   init file.

#2 is intermediate between 1 & 3.  My preference
is for #3: we just bite the bullet and nudge
users helpfully toward using a separate file.

My reason:

#3 is most likely to achieve the desired outcome.
Only users who really want to not have Customize
use a separate file will do so.  And those users
are more likely to be familiar with Emacs Lisp and
know why they really want Customize to tamper with
their init file.

We should especially want to get away from naive
or ignorant users wrt Customize and Elisp getting
into trouble because of mixing user editing with
Customize editing of the same file.

I'm not so worried about those users grumbling
here about having to explicitly set `custom-file'
to their init file (or to nil), to keep Customize
writing to their init file.  In fact, I'm not
worried about them at all.