From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: Re: Calling (package-initialize) sooner during initialization Date: Sat, 18 Apr 2015 19:23:23 +0100 Message-ID: References: <87383xk4ia.fsf@taylan.uni.cx> <87pp71ia87.fsf@taylan.uni.cx> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1429381411 22453 80.91.229.3 (18 Apr 2015 18:23:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Apr 2015 18:23:31 +0000 (UTC) Cc: Stefan Monnier , emacs-devel To: =?UTF-8?B?VGF5bGFuIFVscmljaCBCYXnEsXJsxLEvS2FtbWVy?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 18 20:23:31 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 1YjXOs-0007Hc-6U for ged-emacs-devel@m.gmane.org; Sat, 18 Apr 2015 20:23:30 +0200 Original-Received: from localhost ([::1]:46521 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjXOr-0000x8-HD for ged-emacs-devel@m.gmane.org; Sat, 18 Apr 2015 14:23:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41480) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjXOo-0000wp-3c for emacs-devel@gnu.org; Sat, 18 Apr 2015 14:23:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YjXOn-00077B-3B for emacs-devel@gnu.org; Sat, 18 Apr 2015 14:23:26 -0400 Original-Received: from mail-lb0-x229.google.com ([2a00:1450:4010:c04::229]:35447) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjXOm-000771-RJ for emacs-devel@gnu.org; Sat, 18 Apr 2015 14:23:25 -0400 Original-Received: by lbbuc2 with SMTP id uc2so104314790lbb.2 for ; Sat, 18 Apr 2015 11:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=UJk4IYgVb/dQrYZwBT8po0nsE+LAa2h6vIXdQLsawfY=; b=hHzOwx8ZzI4WafBYvGoEUgMfTzzSlCIfpOgb15sqy4zAyOjZidVGxMwsQGDwTUJjEO 0sQvGE1QB1iJ9fq1lca4TCpKIHTpy6H5Xyv1kYqKawXZUOAwn0St1YFmVHmPYIizrvjS +tE4SgrSDaXUfnoLUhcQlvVAg/dxCBBwG39t1VokdnS2+mqx9vJrP6U8lmPdqClo1s/U xvDutsXDRpJlT53isl6sA/x7lBlO5ZItEwKEYdSCLPHW63nINcdzWAylzNi853wNZ2dB eMdEK/PQsBi87wT4LKD3NB59F6xa2ElZYeWqgEqvKynfqccIBcbMHtQd9EK5kIOphi6A kWcA== X-Received: by 10.112.97.202 with SMTP id ec10mr9140200lbb.4.1429381403893; Sat, 18 Apr 2015 11:23:23 -0700 (PDT) Original-Received: by 10.25.150.1 with HTTP; Sat, 18 Apr 2015 11:23:23 -0700 (PDT) In-Reply-To: <87pp71ia87.fsf@taylan.uni.cx> X-Google-Sender-Auth: aooD-EmXgsOIQRgZpqZ9v4wBeJo X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::229 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:185624 Archived-At: 2015-04-18 19:04 GMT+01:00 Taylan Ulrich Bay=C4=B1rl=C4=B1/Kammer : > Stefan Monnier writes: > >> 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. Yes. It's not completely orthogonal, as the problems are related. But things like "have package-initialize be called by customize-set-variables" will not solve the problem, because the problem goes beyond custom.el. > How about Customize being "smart" and separating package-related > configurations from other ones? I don't know how hard it would be to > implement custom.el would have to make a new defcustom keyword availabe (something like `:before-package'), and then package.el (and any other packages that need this) would simply set that keyword. > 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. I think "4. init.el + All other customization." would be more accurate, as the two are currently loaded together (and separating them, if we want to, is another discussion entirely). > Would that work? AFAICS, yes. I'm not in love with the complexity of this solution. However, I do believe it solves both problems (the custom.el issue and the general package.el issue), and I believe there's no way to do that with a simpler solution. So, I guess I'm saying I'm ok with this if nobody has a better idea.