unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: "tomas@tuxteam.de" <tomas@tuxteam.de>,
	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: RE: FW: [External] : Re: Propose to add setup-wizard.el to ELPA
Date: Wed, 5 Jan 2022 07:43:55 +0000	[thread overview]
Message-ID: <SJ0PR10MB5488D088225C1F3F0F320216F34B9@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <YdUsa+7YPsbNkwxR@tuxteam.de>

> > @@>>>> 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
file.

> 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	other threads:[~2022-01-05  7:43 UTC|newest]

Thread overview: 116+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-02  2:07 Propose to add setup-wizard.el to ELPA Yuan Fu
2022-01-02  2:37 ` Po Lu
2022-01-02  3:02   ` Yuan Fu
2022-01-02  3:22     ` Po Lu
2022-01-02  5:51       ` Yuan Fu
2022-01-02  6:30         ` Po Lu
2022-01-02  7:58           ` Yuan Fu
2022-01-02  8:07             ` Po Lu
2022-01-02  9:07               ` Yuan Fu
2022-01-02  9:22                 ` xenodasein--- via Emacs development discussions.
2022-01-02  9:45                   ` Eduardo Ochs
2022-01-02  9:45                   ` Po Lu
2022-01-02 10:09                     ` Eduardo Ochs
2022-01-02 10:15                       ` Po Lu
2022-01-02 10:25                         ` Eduardo Ochs
2022-01-02 10:34                           ` xenodasein--- via Emacs development discussions.
2022-01-02 10:52                             ` Eli Zaretskii
2022-01-02 10:57                               ` xenodasein--- via Emacs development discussions.
2022-01-02 11:14                                 ` Eli Zaretskii
2022-01-02 11:30                                   ` xenodasein--- via Emacs development discussions.
2022-01-02 11:38                                     ` Eli Zaretskii
2022-01-02 12:01                                     ` Po Lu
2022-01-02 11:31                                   ` xenodasein--- via Emacs development discussions.
     [not found]                             ` <CADs++6jtFBah1hhsuN6T_-kFyjc_pNmmVKA+16vOWa8OctOZLw@mail.gmail.com>
2022-01-02 11:02                               ` xenodasein--- via Emacs development discussions.
2022-01-02 11:17                             ` Po Lu
2022-01-02 11:36                               ` xenodasein--- via Emacs development discussions.
2022-01-02 12:03                                 ` Po Lu
2022-01-02 15:27                                 ` Stefan Kangas
     [not found]                               ` <MsPZqa9--3-2@tutanota.de-MsP_1xO----2>
2022-01-02 11:57                                 ` xenodasein--- via Emacs development discussions.
2022-01-02 12:05                                   ` Po Lu
2022-01-02 15:27                                   ` Stefan Kangas
2022-01-02 15:37                                     ` Eli Zaretskii
2022-01-02 16:43                                       ` xenodasein--- via Emacs development discussions.
2022-01-02 17:32                                         ` Stefan Kangas
2022-01-02 18:51                                         ` FW: [External] : " Drew Adams
2022-01-02 19:07                                           ` xenodasein--- via Emacs development discussions.
2022-01-02 21:29                                             ` Drew Adams
2022-01-02 22:14                                               ` Stefan Kangas
2022-01-03  6:42                                                 ` Sean Whitton
2022-01-03  7:02                                                   ` Stefan Kangas
2022-01-03  8:19                                                     ` xenodasein--- via Emacs development discussions.
2022-01-03  9:27                                                       ` Po Lu
2022-01-03  9:55                                                         ` xenodasein--- via Emacs development discussions.
2022-01-03 10:10                                                           ` Po Lu
2022-01-03 10:21                                                             ` xenodasein--- via Emacs development discussions.
2022-01-03 10:53                                                               ` Po Lu
2022-01-03 11:07                                                                 ` xenodasein--- via Emacs development discussions.
2022-01-03 11:25                                                                   ` Po Lu
2022-01-03 11:32                                                                     ` xenodasein--- via Emacs development discussions.
2022-01-03 12:13                                                                       ` Po Lu
2022-01-03 12:20                                                                         ` xenodasein--- via Emacs development discussions.
2022-01-03 12:32                                                                           ` Po Lu
2022-01-03 12:44                                                                             ` xenodasein--- via Emacs development discussions.
2022-01-03 12:55                                                                               ` Po Lu
2022-01-03 13:24                                                                                 ` xenodasein--- via Emacs development discussions.
2022-01-03 15:15                                                                                 ` xenodasein--- via Emacs development discussions.
2022-01-03 16:04                                                       ` Drew Adams
2022-01-04 21:19                                                     ` Sean Whitton
2022-01-04 21:28                                                       ` Drew Adams
2022-01-04 22:38                                                         ` Sean Whitton
2022-01-04 22:51                                                           ` Drew Adams
2022-01-05  5:28                                                         ` tomas
2022-01-05  7:43                                                           ` Drew Adams [this message]
2022-01-05  8:13                                                             ` tomas
2022-01-07 10:34                                                     ` Jean Louis
2022-01-03 16:03                                                   ` Drew Adams
2022-01-03 16:05                                                   ` Stefan Monnier
2022-01-04  1:50                                                     ` Yuan Fu
2022-01-04  2:53                                                       ` Po Lu
2022-01-04  4:13                                                       ` Stefan Monnier
2022-01-04  4:30                                                         ` Yuan Fu
2022-01-04  6:10                                                           ` Stefan Monnier
2022-01-04 15:04                                                       ` Lars Ingebrigtsen
2022-01-04 21:25                                                         ` Sean Whitton
2022-01-05  0:58                                                           ` Po Lu
2022-01-05 15:35                                                           ` Lars Ingebrigtsen
2022-01-06  6:32                                                             ` Sean Whitton
2022-01-03  0:42                                         ` Po Lu
2022-01-02 18:47                                       ` [External] : " Drew Adams
2022-01-02 11:58                             ` Philip Kaludercic
2022-01-07 10:09                     ` Jean Louis
2022-01-02 18:47                   ` [External] : " Drew Adams
2022-01-02  9:41                 ` Po Lu
2022-01-02 17:18                   ` Yuan Fu
2022-01-02 18:47                     ` [External] : " Drew Adams
2022-01-07 10:02               ` Jean Louis
2022-01-07 10:50                 ` Po Lu
2022-01-07 12:11                 ` Eli Zaretskii
2022-01-09 22:54                   ` Yuan Fu
2022-01-10  4:15                   ` Jean Louis
2022-01-10 15:45                     ` [External] : " Drew Adams
2022-01-10 17:24                     ` Eli Zaretskii
2022-01-11  4:47                       ` Jean Louis
2022-01-11  4:51                     ` Richard Stallman
2022-01-02  7:55 ` Eli Zaretskii
2022-01-02  8:07   ` Yuan Fu
2022-01-02 15:42     ` Stefan Kangas
2022-01-02 17:26       ` Yuan Fu
2022-01-02 17:36         ` xenodasein--- via Emacs development discussions.
     [not found]         ` <MsQrOAf--J-2@tutanota.de-MsQrQR2----2>
2022-01-02 17:55           ` xenodasein--- via Emacs development discussions.
2022-01-02 18:50         ` Stefan Kangas
2022-01-02 21:14           ` Yuan Fu
2022-01-03  0:45             ` Po Lu
2022-01-03  0:59               ` Yuan Fu
2022-01-03  1:02             ` Stefan Kangas
2022-01-03  9:12             ` Joost Kremers
2022-01-03 12:49               ` Eli Zaretskii
2022-01-03 13:00                 ` Po Lu
2022-01-03 19:30                 ` Joost Kremers
2022-01-02  8:07   ` Po Lu
2022-01-02 15:23     ` nanjunjie
2022-01-03  8:28       ` Philip Kaludercic
2022-01-04 16:09         ` Nan JunJie
2022-01-04 19:45           ` Philip Kaludercic
2022-01-02 12:02 ` Philip Kaludercic
2022-01-07  9:58 ` Jean Louis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SJ0PR10MB5488D088225C1F3F0F320216F34B9@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=tomas@tuxteam.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).