all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Radon Rosborough <radon.neon@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
Subject: Re: Friendly discussion about (package-initialize)
Date: Thu, 10 Aug 2017 12:31:01 -0700	[thread overview]
Message-ID: <CADB4rJG7XxJcB8nmsY0ok4UFZ0oCgDpuJcSKJLZ-9X8=ESDndw@mail.gmail.com> (raw)
In-Reply-To: <83bmnns0jm.fsf@gnu.org>

> I'm probably missing some details here

I'm missing some details too, since I don't use the Custom system, and
that seems to have been part of this discussion in the past. I expect
that the fact there are so many details is what makes this discussion
keep coming up, because nobody's solution caters to every use case.

> using hooks is not such scary stuff for new users

Fine, but do we really want to tell users to put the entirety of their
init-file inside `after-init-hook'? That seems like an anti-pattern to
me. It's either `package-initialize' which has to move, or the entire
rest of the init-file. It makes more sense to me to move
`package-initialize'.

> new users aren't expected to mess with this anyway

So if we implemented a template init-file, then new users who didn't
have a init-file previously would not need to do anything.
Furthermore, existing users who are comfortable with customizing Emacs
would not have a problem either, since the concept of "you must
initialize the package management system before you can use packages"
is trivially simple. The only people disadvantaged are new users who
already had an existing init-file.

If we keep calling `package-initialize' in startup.el, then things
will work as expected for these users as well, unless they happen to
manually write some customizations of packages into their init-file.
But now the set of users who are disadvantaged is limited to:

1. new users
2. who aren't comfortable with modifying their init-file
3. who nevertheless had an existing init-file
4. and nevertheless add Lisp code directly to their init-file anyway

In my opinion, this is a rather narrow intersection, and the problems
introduced by automatic modification of the init-file far outweigh the
inconvenience to this group of users.

> that doesn't really answer my question. I asked why do we put a call
> to package-initialize into user init file when we already have that
> very call in startup.el.

You'll have to ask Stefan. I am the one arguing that this behavior
makes no sense and should be eliminated ASAP.

In short, however, this measure was introduced in an effort to allow
for package customizations to be put in the init-file without
`package-initialize' also being put in the init-file (by the user).

best,
Radon



  reply	other threads:[~2017-08-10 19:31 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-07  0:37 Friendly discussion about (package-initialize) Radon Rosborough
2017-08-07  1:39 ` Stefan Monnier
2017-08-07  2:16   ` Radon Rosborough
2017-08-07  2:44     ` Stefan Monnier
2017-08-07  4:12       ` Radon Rosborough
2017-08-09 20:24         ` Stefan Monnier
2017-08-10  3:32           ` Radon Rosborough
2017-08-10  4:25             ` Eli Zaretskii
2017-08-10  4:39               ` Radon Rosborough
2017-08-10  7:24                 ` Eli Zaretskii
2017-08-10 17:06                   ` Radon Rosborough
2017-08-10 19:08                     ` Eli Zaretskii
2017-08-10 19:31                       ` Radon Rosborough [this message]
2017-08-10 20:00                       ` Mark Oteiza
2017-08-11  6:14                         ` Eli Zaretskii
2017-08-11  1:25                     ` Nick Helm
2017-08-11 21:43                       ` Stefan Monnier
2017-08-09 20:35         ` Interoperation between package managers (was: Friendly discussion about (package-initialize)) Stefan Monnier
2017-08-10  3:54           ` Radon Rosborough
2017-08-10 21:34             ` Interoperation between package managers Stefan Monnier
2017-08-11  2:14               ` Radon Rosborough
2017-08-11 22:05                 ` Stefan Monnier
2017-08-12 17:54                   ` Radon Rosborough
2017-08-12 20:53                     ` Jonas Bernoulli
2017-08-13 21:43                       ` Stefan Monnier
2017-08-13 21:25                     ` Stefan Monnier
2017-08-13 22:42                       ` Radon Rosborough
2017-08-13 23:32                         ` Stefan Monnier
2017-08-14  0:29                           ` Radon Rosborough
2017-08-14  8:02                             ` Stefan Monnier
2017-08-23 19:39             ` Nikolay Kudryavtsev
2017-08-23 20:58               ` Radon Rosborough
2017-08-24 12:36                 ` Nikolay Kudryavtsev
2017-08-24 20:11                   ` Radon Rosborough
2017-08-25 14:31                     ` Nikolay Kudryavtsev
2017-08-24 15:04               ` Ted Zlatanov
2017-08-24 15:46                 ` Nikolay Kudryavtsev
2017-08-07  3:20   ` Friendly discussion about (package-initialize) Noam Postavsky
2017-08-07  4:14   ` Mark Oteiza
2017-08-08  0:47     ` Stefan Monnier
2017-08-10 20:15       ` Mark Oteiza
2017-08-10 21:29         ` Stefan Monnier
2017-08-11  1:14           ` Mark Oteiza
2017-08-11  8:03             ` Clément Pit-Claudel
2017-08-07  6:52 ` Colin Baxter

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

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

  git send-email \
    --in-reply-to='CADB4rJG7XxJcB8nmsY0ok4UFZ0oCgDpuJcSKJLZ-9X8=ESDndw@mail.gmail.com' \
    --to=radon.neon@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.