From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Friendly discussion about (package-initialize) Date: Thu, 10 Aug 2017 22:08:45 +0300 Message-ID: <83bmnns0jm.fsf@gnu.org> References: <83inhwrqvh.fsf@gnu.org> <83h8xfsx5m.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1502392202 27326 195.159.176.226 (10 Aug 2017 19:10:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 10 Aug 2017 19:10:02 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Radon Rosborough Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 10 21:09:57 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dfsq9-0006ZV-5o for ged-emacs-devel@m.gmane.org; Thu, 10 Aug 2017 21:09:53 +0200 Original-Received: from localhost ([::1]:54856 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dfsqF-0000m8-Bx for ged-emacs-devel@m.gmane.org; Thu, 10 Aug 2017 15:09:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54947) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dfsph-0000m0-9v for emacs-devel@gnu.org; Thu, 10 Aug 2017 15:09:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dfspc-0002xC-VO for emacs-devel@gnu.org; Thu, 10 Aug 2017 15:09:25 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59518) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dfspc-0002x8-Rr; Thu, 10 Aug 2017 15:09:20 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3696 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dfspa-0000mC-BV; Thu, 10 Aug 2017 15:09:20 -0400 In-reply-to: (message from Radon Rosborough on Thu, 10 Aug 2017 10:06:34 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:217397 Archived-At: > From: Radon Rosborough > Date: Thu, 10 Aug 2017 10:06:34 -0700 > Cc: Stefan Monnier , emacs-devel@gnu.org > > Now there is also the question of where it is appropriate to call > `package-initialize'. IMO, the only appropriate place to call it is in > the user's init-file. Doing it anywhere else smells like unnecessary > magic, and limits customizability. For example, calling it in > startup.el after loading the init-file means that package > customizations cannot be put in the init-file (unless you use > `after-init-hook', an advanced and rather nonstandard approach), but > the package management system still works after init. Can you possibly > think of any setup that would be *more* confusing to new users? I'm probably missing some details here, but in principle I don't see here anything that should be confusing or hard to get right. We do that with other tricky stuff, like customizations of the basic faces, which we read from .emacs after Emacs already started and displayed its first frame. And using hooks is not such scary stuff for new users, either. To say nothing of the fact that new users aren't expected to mess with this anyway, they should just use what package installation procedure arranged for. > > If we call package-initialize from startup.el, why does it have to > > also be called from the init files? > > IMO, it should not be called anywhere. I think having it only called > in startup.el would be a reasonable compromise. Having Emacs insist on > putting the call into the init-file, but then *also* calling it in > startup.el, makes no sense. Thanks, but 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.