[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: FW: [External] : Re: Propose to add setup-wizard.el to ELPA

From: Drew Adams
Subject: RE: FW: [External] : Re: Propose to add setup-wizard.el to ELPA
Date: Wed, 5 Jan 2022 07:43:55 +0000

> > @@>>>> Customize should not write to your init file ...
> > @@>>>> That's a bad Emacs design choice, IMO.
> > @@>>>> It especially should not be the default behavior.
> > > >>>
> > > >>> +1, FWIW.
> > > >> Hmm, then where should it write to?
> > > > IMO, something like
> > > > (setq custom-file (locate-user-emacs-file "custom-file.el"))
> > >
> > > Hmm.  I recently deleted something like that which had been in my init
> > > for years, because I looked it and couldn't come up with a reason why
> > > the code should be in a separate file.  It seemed like pointless
> > > complexity.  Why do you think it's better that way?
> >
> > Go to @@.
> Where's @@? (genuine question: I don't know
> what you want to convey with that expression :)

Sorry, I just meant the first 3 lines of the
mail.  I then added this for the reason:

> > Mixing hand coding and automatic coding in the same
> > file is error-prone.  It's just asking for trouble.
> > And it's not needed.
> And this is the point where your (respected,
> mind you) opinion enters the scene. 

Call it an opinion, if you like.  I don't see it
as very controversial to think it's a bad idea
to have (all kinds of) users editing generated
code, and have a file that includes user code
along with code edited automatically.

The there-be-dragons warning you refer to is,
to me, evidence of potential problems waiting
to happen.

Emacs should of course let users do that (mix
the two in the same file).  Emacs has a fine
tradition of giving users plenty of rope, of
all sizes, lengths, and colors, to hang
themselves with - and that's a good thing.

The point is just to not have Emacs do that
mixing by default.

The default behavior of Emacs now is to have
a single file that mixes user coding and
Custom coding.  Why is that a great idea?

Many (most?) users should never even need to
look at the code that Customize produces to
save their preferences.

> We're taking that risk all the time whenever several people
> work on the same code. You might argue they understand the code they're
> changing, but then, we are doing it mechanically too, whenever we do a
> VC merge, and this relies generally on simple textual distance to
> "declare" that two changes are independent. Courage :)

There are differences of degree/quantity, that
can lead to differences of quality.  Not everyone
putting some code into their init file is at the
same level of familiarity with Elisp (let alone
with Customize code).

Many users who put something in their init file
are not "working on code" in the way you describe.
Not every Emacs user is a programmer, and not
every programmer is familiar with Lisp.  But most
users will have an init file, however rudimentary,
and many will use Customize in one way or another.

You can edit bookmarks in your bookmark file too.
But you don't generally do that.  And yes, for
pretty much anyone doing stuff like that, it can
be error prone.  In Bookmark+ I give you an easy
way to do that, but I don't expect most users of
bookmarks to edit their code.  Likewise, desktop
files and other such.  There's a reason we put
such generated "configuration" code in its own

> Having a comment marker
> ;; here be lions
> ...
> ;; end of lions
> ... as customize has been doing --uh-- customarily should suffice
> perfectly (for some users, some contexts).

Yes, it's fine "for some users, some contexts".
We've done it for all users, all contexts, by
default for 40 years, and the globe hasn't
stopped spinning.  That doesn't mean it's the
best approach.

And users would still be able to do everything
in their init file, and still have Customize
write to that file if they want, as I explained.

There's no limitation or obligation.  What would
change is the default behavior.  You might not
be someone who would benefit by this change.
You wouldn't be forced to suffer the separation.

> As for what should be the recommended way, I still agree with you 100%.
> I still don't agree that there should be extra code to enforce that.

It's not clear to me what you agree with me
about, or what extra code you mean.

That Customize should, by default, write to a
separate file, is what I'm arguing for.  If
you agree with that, great.

How best to realize that separation-by-default
is a secondary question.  The first hurdle is
the main one.  The first is the what, the
second is the how.  I care more about the what.

> What would make me happy is to supply a minimal init.el file already
> containing the "include" and a minimal (empty) custom.el for new
> installations.

Not sure I understand you.  Are you saying
that Emacs could or should provide a starting
init file, which defines `custom-file' in some
standard location and which loads that file at
the end?

That's one possibility (for separating where
Customize writes, by default).

A priori I don't favor such an approach (it
might itself be confusing & error prone), but
it's a design to consider.

We're far from deciding _how_ to support
separation of custom-file & init file.  The
first step is convincing the powers that be
that such separation is desirable, by default.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]