From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Calling (package-initialize) sooner during initialization Date: Sun, 19 Apr 2015 06:44:19 +0000 Message-ID: References: <87383xk4ia.fsf@taylan.uni.cx> <87pp71ia87.fsf@taylan.uni.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bacbd4893afd705140e2454 X-Trace: ger.gmane.org 1429425877 14283 80.91.229.3 (19 Apr 2015 06:44:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Apr 2015 06:44:37 +0000 (UTC) Cc: Artur Malabarba , emacs-devel To: =?UTF-8?B?VGF5bGFuIFVscmljaCBCYXnEsXJsxLEvS2FtbWVy?= , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 19 08:44:37 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yjiy3-0004kc-NB for ged-emacs-devel@m.gmane.org; Sun, 19 Apr 2015 08:44:35 +0200 Original-Received: from localhost ([::1]:47661 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yjiy3-0007pU-4G for ged-emacs-devel@m.gmane.org; Sun, 19 Apr 2015 02:44:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53955) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yjixp-0007p8-Js for emacs-devel@gnu.org; Sun, 19 Apr 2015 02:44:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yjixo-0002gK-Ah for emacs-devel@gnu.org; Sun, 19 Apr 2015 02:44:21 -0400 Original-Received: from mail-wi0-x236.google.com ([2a00:1450:400c:c05::236]:38178) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yjixn-0002fg-V3 for emacs-devel@gnu.org; Sun, 19 Apr 2015 02:44:20 -0400 Original-Received: by wiun10 with SMTP id n10so59195770wiu.1 for ; Sat, 18 Apr 2015 23:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=sUItzq5FbOWIx92edPSGLZoi2zqJ2R4Q4TIKcd2ndgM=; b=LcEzr2hSzUoZn4lXF/0oZRcuXjKVzbNerA3HpU9aR2SNZmR5rFiIGEPy4PfaYSCit9 iP5KH+brdf7m8PD0RNunD187AXC0x6VpBqk7X5LoAo9YJEp1eBMAK9X8CcBxKgQB/+uM Ev/PouDir78fhVZ4XRTpQBhY4yN682a5U4dxhYdNKP09XELItFRyypjEoYKDhc2pC9MU vktjyt+TdxZOV4i8MihIuvaHH2FV9ZzuZUkYFajDLyVMgZZEAhhd02DXUXDumfC+R+kF wtiOA0u3hCKJTQmiWaejgA58+CufRoclO7yC90SwvsglnVlCgRIIaF0bmnJ2O9fXAlBg BlfQ== X-Received: by 10.194.93.195 with SMTP id cw3mr20512274wjb.150.1429425859307; Sat, 18 Apr 2015 23:44:19 -0700 (PDT) In-Reply-To: <87pp71ia87.fsf@taylan.uni.cx> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::236 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:185658 Archived-At: --047d7bacbd4893afd705140e2454 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Taylan Ulrich Bay=C4=B1rl=C4=B1/Kammer schrieb am= Sa., 18. Apr. 2015 um 20:04 Uhr: > Stefan Monnier writes: > > > I think all those discussions are missing the point. > > If we want to improve the system to the point of considering adding new > > init files, then we should try and fix other problems at the same time. > > > > So here's one of the larger problems: > > > > How can we make the system work such that the user can: > > - Use customize to set package-user-dir, package-pinned-packages, etc..= . > > - Use customize to configure a variable which has a :require which load= s > > a file that's only available after calling package-initialize. > > The first requires package-initialize to be called late, the second > > requires package-initialize to be called early. > > > > Maybe a solution is to simply make customize-set-variables lazier, so > > that variables with a :require see their setting delayed to after > > package-initialize was called. Or else, have package-initialize be > > called by customize-set-variables. Or... > > I'm not sure if this isn't an orthogonal problem, but indeed as someone > who doesn't use Customize I didn't think about it at all, and know > little about it so excuses in advance for ignorance. > > How about Customize being "smart" and separating package-related > configurations from other ones? I don't know how hard it would be to > implement, but it feels like the right design; obviously package related > customization should be applied before package-initialize, but all other > customization should be applied after package-initialize, since it's a > configuration system, meaning it should be one layer above the package > system, going purely by intuition. > > So startup would look like: > > 1. pre-package-init.el > 2. Package related customization. > 3. package-initialize > 4. init.el > 5. All other customization. > > Would that work? > I think that would be a good solution, although I'd modify it a bit: 1. Contents of init.el before applying customizations. 2. Applying customizations, either inline in init.el or by loading custom.el from init.el 2.a. Package related customization 2.b. package-initialize 2.c. All other customization 3. Rest of init.el That would be closer to the current behavior and eliminate the need for pre-package-init.el. --047d7bacbd4893afd705140e2454 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Taylan Ulrich Bay=C4=B1= rl=C4=B1/Kammer <taylanbayirl= i@gmail.com> schrieb am Sa., 18. Apr. 2015 um 20:04=C2=A0Uhr:
Stefan Monnier <monnier@IRO.UMontreal.CA> writes:<= br>
> I think all those discussions are missing the point.
> If we want to improve the system to the point of considering adding ne= w
> init files, then we should try and fix other problems at the same time= .
>
> So here's one of the larger problems:
>
> How can we make the system work such that the user can:
> - Use customize to set package-user-dir, package-pinned-packages, etc.= ..
> - Use customize to configure a variable which has a :require which loa= ds
>=C2=A0 =C2=A0a file that's only available after calling package-ini= tialize.
> The first requires package-initialize to be called late, the second > requires package-initialize to be called early.
>
> Maybe a solution is to simply make customize-set-variables lazier, so<= br> > that variables with a :require see their setting delayed to after
> package-initialize was called.=C2=A0 Or else, have package-initialize = be
> called by customize-set-variables.=C2=A0 Or...

I'm not sure if this isn't an orthogonal problem, but indeed as som= eone
who doesn't use Customize I didn't think about it at all, and know<= br> little about it so excuses in advance for ignorance.

How about Customize being "smart" and separating package-related<= br> configurations from other ones?=C2=A0 I don't know how hard it would be= to
implement, but it feels like the right design; obviously package related customization should be applied before package-initialize, but all other customization should be applied after package-initialize, since it's a<= br> configuration system, meaning it should be one layer above the package
system, going purely by intuition.

So startup would look like:

=C2=A0 1. pre-package-init.el
=C2=A0 2. Package related customization.
=C2=A0 3. package-initialize
=C2=A0 4. init.el
=C2=A0 5. All other customization.

Would that work?

I think that would be a good solution, alt= hough I'd modify it a bit:

1. Contents of init= .el before applying customizations.
2. Applying customizations, e= ither inline in init.el or by loading custom.el from init.el
=C2= =A0 2.a. Package related customization
=C2=A0 2.b. package-initia= lize
=C2=A0 2.c. All other customization
3. Rest of ini= t.el

That would be closer to the current behavior = and eliminate the need for pre-package-init.el.=C2=A0
--047d7bacbd4893afd705140e2454--