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

[Drew Adams]

> >> There goes the _most_ important aspect of this:
> >> it's been around for a long time, which is
> >> precisely why it's a great idea to stick with it.
> >
> > What part of "no, I'm not saying this isn't
> > important", did you have trouble with?
> 
> You proceeded to dismiss the importance of that problem.

No, not at all.

I asked that, "for a second", we abstract
from that problem to consider what behavior
we'd think was best without it.  I wanted to
know what we think is the better approach,
other things being equal - as a starting
point for discussion.

If it's not even considered generally better,
in the abstract, to separate hand-coding and
generated code, then there's no need to add
an a fortiori argument of "it's longstanding".

To make such a change, a minimal starting
point is agreeing that, other things being
equal, separate is better.  Disagreement on
that means no sense in going further.

And yes, "other things being equal" is an
expression which takes for granted that other
things need NOT be equal.  It doesn't at all
dismiss their importance.

> > > it's too established to change now, no
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > matter how good an idea the change is.
> >
> > That's a pretty broad argument.  It argues
> > against pretty much all of the small & large
> > changes Emacs has undergone over the last
> > couple of decades.  It's a blanket argument
> > against both good & bad changes.
> 
> This is not an addition of a new feature, which
> should be off by default if it interferes with
> existing code (think lexical binding).

Doesn't matter to your statement, which was
only that if something is longstanding then
it should be kept - a blanket argument for
keeping the status quo, what's "established".

The lack of lexical binding was longstanding.
That lack was removed (thank goodness).

> It is a change to very long-standing behaviour
> that is also relied on by many people.

The absence of a `custom-file' by default
is "relied on"?  How so?  What would giving
`custom-file' a default value deprive anyone
of?

No one has suggested that anyone _has_ to
use a separate custom file, just as now no
one says that everyone _must not_ use a
separate file.

> > (Think how long the lack of lexical
> > binding was "established".)
> 
> And lexical binding is still optional, 

But there's no longer any lack of it.  A
change was introduced, bucking your rule of
not changing whatever's long been the case.

> so the use of dynamic binding by default
> is as established as it used to be.

What was established was that there was
_only_ dynamic binding.  That's no longer
the case.

> > This change would cause no such disruption.
> 
> It might not for you, but would for a lot of people.

How so?  Are you talking about a minority
of users having to explicitly say that
they don't want a separate file - e.g.
simply setting `custom-file' to nil?

As opposed to the majority having to say
that they do want a separate file?

I'm assuming you agree it's generally
better, for more people than not, to
use a separate `custom-file'.

There are more future than past users,
and for a new user the "other thing"
of longstanding habit doesn't apply.
There may be still "other things" to
consider (what?), but that one is moot
for new users.