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

[Drew Adams]

> From your response, there are a couple of additional
> points I'd like to make to clarify some things.
> 
> The reason I don't think just setting the custom file
> to some value really covers the full scope of the
> change is because in addition to that change, it will
> also be necessary to add code to make emacs load that file.

I assume you mean load that file _automatically_,
since users can (and do) already load it in their
init files.

Automatically loading `custom-file', if it isn't
loaded by the init file (and any code that file
loads etc.), is not a hard requirement.

It's something that could easily be done, but it's
not _required_ to advance the aim of getting more
users aware of and using `custom-file'.

> This means either the timing of loading that file would then
> be up to Emacs or we would have to add some other switch to disable
> automatic loading to restore user control over loading that file.

Yes.  But I think that can be as simple as what
I suggested:

1. Automatically load `custom-file' (provided it's
   not the same as the init file) immediately after
   the init file is loaded.

   (We already automatically load other files if
   they exist - site-lisp.el etc.)

2. Provide users with a way to inhibit automatic
   loading if they need/want to do that.

(Those users who want to do everything in their
init file are not involved in this - they'd
just set `custom-file' to their init file.)

> So already the 'simple' change proposal has added additional complexity
> (albeit small). 

As I say, automatic loading isn't a requirement.
It's a feature.  And with #2 it's optional.

(One way to realize #2 would be with a user
option.  We could discuss its default value.)

> There could be other corner cases I've not thought of as
> well, especially once we add a new 'toggle' for the loading behaviour.

If we're really worried about that, then we
just don't provide any such automatic loading.

I don't expect problems, but automatic loading
isn't a requirement.  Nothing in the general
aim and proposed solutions requires it.

Without it, users would just be responsible for
loading `custom-file' - like now.  Not a big
deal, but I think it might help users to provide
it (new users especially).

> The change management aspects I referred to are perhaps a little subtle
> and are certainly hard to quantify. However, it is often way too easy to
> underestimate the impact of such change and identify what needs to be
> done to mitigate it. This impact can be especially hard to recognise
> when you are invested in the change.

I don't disagree with that general point.

I don't foresee any complications, but I'm
_not_ really invested in Emacs providing the
ability to automatically load `custom-file'.

> Things which need to be considered
> (some of which have been mentioned) include
> 
> - dealing with impact on existing users
> - updating documentation, including manuals, howtos, faqs etc
> - managing the confusion that will arise due to the amount of existing
>   and easily found information out there (stack overflow, reddit, wikki,
>   blogs, books etc) which will be out of date and will likely cause more
>   confusion.

Sure.

> Just dealing with the first one will likely result in the final solution
> being more complex than simply setting a default custom file value,
> which in turn will make the other points more substantial to deal with.

I don't think so, but I can't prove you're wrong.

Suppose we don't offer automatic loading.
If you don't load `custom-file' (from your
init file or in some other way) then it doesn't
get loaded.  End of story.

Or suppose we offer it, but by way of a user
option that by default is off (no autoload).

IOW, no change from what we do now, in this
respect (no autoloading of `custom-file').

In that case, the change is just to default
`custom-file' to a standard location, not to
nil.  Now reread your paragraph of things that
need to be considered.  Not a big deal in this
case, right?

I wouldn't be completely happy with that
solution, but it would still be an improvement.

As I said, it would even be a (small)
improvement if Emacs would just come out and
recommend to users to use `custom-file',
instead of just warning them, in the init-file
template-comment, not to edit the inserted
generated code.

I'd hope that we go further than that, but
even that would help.

> The above are some of the reasons I think it may be misleading to
> characterise the proposal as something simple. 

"The proposal" is really a set/hierarchy of
proposals, from trivially simple, with little
effect (and I hope little controversy), to
something that includes possibly automatically
loading `custom-file'.

I hope you'll agree that the mere change to
defaulting `custom-file' to a file name isn't
complicated in its implications, and it should
not be controversial.

All of what would happen in that case already
happens, if a user sets `custom-file' to a
file name.  If no one loads that file, or if
that file remains nonexistent or empty, we're
in no-op land.

Even users who only want to use their init
file for customizations wouldn't be impacted.
No-op.

> However, I would be in support if I thought
> this was an actual problem needing to be addressed.

Maybe think of it as what we have now: offering
`custom-file', but just making use of it a bit
more visible and likely.  Instead of thinking
"problem" and "solution", maybe just think that
it might help more users to take advantage of
`custom-file'.

> TO me, it really does feel more like a solution in search of a problem
> or at the very least, a change which will result in non-trivial effort
> (at various levels) when there is little evidence it is really required.

I understand that you feel that.  I think your
fears are unnecessary.  Take out the "automatic
loading" feature from your consideration, and
see how fearful you still are.