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

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

> I would very much prefer to be able to use a single file to contain my
> hand-coded configurations as well as to save customizations.

There's been some misinterpretation, if not
misinformation, about what's actually been
proposed.

Nothing, in what's been proposed, would
prevent anyone from using only their init
file, i.e., continuing to have Customize
save settings to their init file.

[And nothing would prevent someone who
 loads `custom-file' already from loading
 it from wherever, whenever s?he likes, and
 as many times as s?he likes.  You didn't
 mention that need, but I mention it because
 this was another misunderstanding some
 introduced here.]

> I found this a very comfortable way to build an emacs configuration
> without understanding elisp over decades.

Yes, indeed.

> During the last couple of years I have learned more elisp (yay, fun!)
> and I don't find any frustration having to set up my custom-file
> explicitly, now that this is something I prefer doing.

Ditto.  I used to use only my init file, and
at some point I started using `custom-file'.

[In my case, I even load `custom-file' twice
 from my init file.  Getting the same effect
 without using a separate `custom-file' could
 be done, but would be tricky and somewhat
 error-prone.]

Or did you mean the opposite?  By "set up my
custom-file explicitly" did you instead mean
set your customizations in my init file, and
let Customize add customizes there?

> During the "middle years", I knew enough to configure a fresh emacs by
> retyping a minimum set of elisp into a .emacs file to get myself
> started from a fresh install.  (I didn't really understand how this
> code I was typing worked, I just knew it made emacs easier for me to
> use.)

Yes!  I tried to make the point that some
users do exactly that.  That counters the
notion that only knowledgeable users add or
edit code in their init files.  Init files
are for everyone, including novices.

> Once my .emacs was created on the newly setup system I would
> use customize to amend the configuration as I used the editor.

Sounds good.

> From that point, I would migrate my configuration from machine to machine
> until I somehow lost the .emacs file, at which point the process would
> start over.
> 
> Placing customized output into the .emacs file meant I had only one
> file to keep track, trying to keep my 'live configuration settings"
> going.

Yes, that can be a definite advantage in some
such situations.

> I didn't find the mixture of hand and machine authored code in my
> configuration file unexpected.   In fact, I consider that most
> programs with a "control panel" seem to work this way:   if I manually
> edit the rc files that work.  If I use the GUI the program updates my
> rc files for me.   In this light, I see the present approach
> (supporting a single .emacs file with all config/customizations in) as
> rather more elegant and showcasing Emacs' expert manipulation of my
> files.

OK.

> Emacs is one of the only programs I trust to edit files for me
> 
> In any case, I would discourage efforts to complicate the minimum set
> of user-space files required to effect a combination of configuration
> and customizations.   I hope that additional understanding of Emacs
> would not be required to reenable this behavior if my perspective
> isn't common among emacs users.

If you mean re-enable having Customize save
to your init file, then no.  No special
understanding would be needed.  You'd just
explicitly set variable `custom-file' to
your init file (or to nil).

> Finally, it's unclear to me where the level of zeal
> toward changing the current behavior is coming from.

I'm not sure there's any zeal in that
direction.

I proposed the change, and I've tried to
give reasons supporting it, replying to
(sometimes zealous) opposition to the
proposal.  I'm pretty tired of replying,
but I've continued to make an effort.
(I did take the weekend off.)

I don't think I've been zealous about our
making such a change.  But I have tried to
be attentive to answering arguments others
have made.

IOW, it's really not a big deal to me
whether Emacs makes such a change.  I think
it would be helpful if it did, but I won't
cry if it doesn't. In fact (as I've said),
I don't expect Emacs will make such a change.

And I don't need the change for my own
benefit.  Whether I use `custom-file' or
not is irrelevant.  (I use it, but that
doesn't matter at all.)

> I can understand that people may
> well not share my view.   I don't understand the
> sense of urgency and supercilious tone.

I don't think my own tone has been supercilious.

Nor have I expressed any sense of urgency.
In fact, I've made the same proposal (but
without specifying details) in the past -
years ago, and perhaps more than once over
the decades.  It's not as if I've suddenly
come up with this idea and insisted that
Emacs must make such a change immediately.

The point in mentioning the saga of
`transient-mark-mode' is that sometimes it
takes a long time, and perhaps more than
one discussion, for a change to be made.

I'm glad this `custom-file' thing is being
discussed now, even if no change comes from
it.

Why?  For one thing, because I'm sure that
some users who are completely unaware of
`custom-file' will start to use it.  And
for another thing, even if `custom-file'
doesn't get used by default anytime soon,
this discussion might contribute to such a
change being made sometime in the future.

> Perhaps I can ask those who strongly disagree
> with my perspective to also share personal stories of how their
> proposed changes would have improved their own use of Emacs over the
> years.

I don't disagree with your perspective at
all.  Your perspective about your personal
use, and all that you say about it, makes
sense to me.

My summary of the main argument for the proposal:

1. Separate files by default is a better
design, in the abstract.

That is, if we hadn't used the same file by
default for decades then I think there'd be
pretty widespread agreement that the design
should be separate files by default.

(The discussion has borne this out, so far.
Even forceful opponents of making the change
have admitted that IF we were starting from
scratch THEN separate files would make more
sense.)

2. All a user would need to do, to get back
the current behavior, would be to explicitly
set `custom-file' to the init file (or nil).
___

More has been argued, but that about sums it
up.  The benefit is a better default behavior.
The cost is that some users would need to add
a `setq' to their init file.

(Which users?  Not necessarily everyone who
today lets Customize save to their init file
will want or need to add that `setq'.  Some
will do so.)