From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Radon Rosborough Newsgroups: gmane.emacs.devel Subject: Re: Summary and next steps for (package-initialize) Date: Thu, 24 Aug 2017 21:28:55 -0700 Message-ID: References: <83tw12cocz.fsf@gnu.org> <83wp5xat6i.fsf@gnu.org> <83pobk9aly.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113f17d67eb21005578c6410" X-Trace: blaine.gmane.org 1503635399 23164 195.159.176.226 (25 Aug 2017 04:29:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 25 Aug 2017 04:29:59 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 25 06:29:49 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 1dl6FZ-00052q-00 for ged-emacs-devel@m.gmane.org; Fri, 25 Aug 2017 06:29:41 +0200 Original-Received: from localhost ([::1]:51446 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dl6Ff-0004B5-Pv for ged-emacs-devel@m.gmane.org; Fri, 25 Aug 2017 00:29:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44844) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dl6FY-0004Aw-RL for emacs-devel@gnu.org; Fri, 25 Aug 2017 00:29:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dl6FX-00087N-Np for emacs-devel@gnu.org; Fri, 25 Aug 2017 00:29:40 -0400 Original-Received: from mail-lf0-x22a.google.com ([2a00:1450:4010:c07::22a]:33308) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dl6FW-00086V-2P; Fri, 25 Aug 2017 00:29:38 -0400 Original-Received: by mail-lf0-x22a.google.com with SMTP id y15so5501093lfd.0; Thu, 24 Aug 2017 21:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CFdaamf8OeTtzS/SJTk9gw8yRGs/qZCj2WBesQQL4hc=; b=G8dv1PCPnclwflB4jGZx5wNLx8YiYoZLjpfbIvXiZEV6PPYCrbutdVWLZutyQLuFtW SL6HpBd2R+hdDK7y3NyTWcvaKqFpXhhBsFZ5Gc+XUqr933B65SjXUm1vP56rjTYMqeiF z6m9dvSfR4gYYOfpOMEfsC7BTcgYE3FwohU3xNHVB+eF7i5eps0oW0P7jUsoGWWnKC49 hOm+ZHj4UHiCYisNv1AQxw8I5Fl1Jcx1ksYcyzjIOUMCzpn/TSADFBW4r/kxQo5ftxwC +HQyT6LGlg0Q8Lfv2FjClCjYrGdDyqiDr4L2nBX/mN6rLkfAm8OFsc0ogpF/3kE38WTh wdqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CFdaamf8OeTtzS/SJTk9gw8yRGs/qZCj2WBesQQL4hc=; b=FfaszhRfH3Ki+E7cHYOGpmcBRs1OH23ecpAqrukI+izpCZwO6SGF8nwc8ivq/Dlsga eALLkFPqjZ8Naj9jrRDkyaD6l6WVRr6ixKeTTuFSpnCONsROx69gzxWImbGAzN3p+VDz 3ZHRYVU2XNmXCG+wjnx82M/rvZ5aZbT1NACGNkHY4Ub1i2frqgDZq9Y94LBD+k4EJNEq lJxv/A7hFa2Kx/iVP9dyFlyfLYgslEu04ZJwRdjm14pPFLP2g10wPJ0gkXBqeYfDWuRk ccb9f47CmbHbBP2LdkOmptsfibVfDRk9+2GmZ0nN2bQx2eBNi9HEH+xTqPk4X6Q9vgyf NmHg== X-Gm-Message-State: AHYfb5izlWqYUzWKyUzKLBhepaQ8CNw+HZ2VG4u2S72H5QScGTfI3ts2 hZXkRPR8jFjOneC3ZT9ipQRKXHmv+w== X-Received: by 10.25.21.94 with SMTP id l91mr2755537lfi.16.1503635376614; Thu, 24 Aug 2017 21:29:36 -0700 (PDT) Original-Received: by 10.25.42.215 with HTTP; Thu, 24 Aug 2017 21:28:55 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::22a 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:217801 Archived-At: --001a113f17d67eb21005578c6410 Content-Type: text/plain; charset="UTF-8" > The ability to undo is useful in general. It's true, but most packages don't provide this capability, so if package.el relies on it, then usage of package.el will produce more bugs. > And while it's true that Emacs can't magically know how to > deactivate a package, in general, the package can provide extra code > that explains how to deactivate itself (e.g. via > -unload-function). That tells how to unload the feature , not how to undo the effects of the autoloads for all features in the package. Sure, the package can provide metadata that tells how to undo its autoloads, but this will be an additional system separate from -unload-function. Unless we want to tell people they have to write their -unload-function so that it works even if unloading a feature that hasn't been loaded yet... > use a separate "early-config" file. Now, you probably wonder why I > say it's "another" idea, so here's the reason: this file would be > loaded before the initial GUI frame is created (so it would solve > another similar problem at the same time, which is "how do I turn > OFF those GUI elements in my .emacs such that they never show up, > not even temporarily while we process the .emacs"). I think this is a really great idea, and would fit in well conceptually. It would also resolve the concern that Nikolay raised earlier about ~/.emacs.d/.package-initialize.el later becoming extraneous if we refactor the feature loading system. > rather than a separate file, accept a special (with-early-config > ...) form at the beginning of the ~/.emacs. I guess I would be fine with this, even though I think it's a little hacky. Best, Radon P.S. I notice you keep saying ~/.emacs. Is that out of habit/convenience? I thought ~/.emacs was deprecated in favor of ~/.emacs.d/init.el. --001a113f17d67eb21005578c6410 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> The ability to undo is useful in gener= al.

It's true, but most packages don't pro= vide this capability, so if
package.el relies on it, then usage o= f package.el will produce more
bugs.

>= ; And while it's true that Emacs can't magically know how to
<= div>> deactivate a package, in general, the package can provide extra co= de
> that explains how to deactivate itself (e.g. via
> <pkg>-unload-function).

That tells ho= w to unload the feature <pkg>, not how to undo the
effects = of the autoloads for all features in the package. Sure, the
packa= ge can provide metadata that tells how to undo its autoloads, but
this will be an additional system separate from <pkg>-unload-functio= n.
Unless we want to tell people they have to write their
<pkg>-unload-function so that it works even if unloading a feature=
that hasn't been loaded yet...

>= use a separate "early-config" file. Now, you probably wonder why= I
> say it's "another" idea, so here's the = reason: this file would be
> loaded before the initial GUI fra= me is created (so it would solve
> another similar problem at = the same time, which is "how do I turn
> OFF those GUI el= ements in my .emacs such that they never show up,
> not even t= emporarily while we process the .emacs").

I t= hink this is a really great idea, and would fit in well
conceptua= lly. It would also resolve the concern that Nikolay raised
earlie= r about ~/.emacs.d/.package-initialize.el later becoming
extraneo= us if we refactor the feature loading system.

>= rather than a separate file, accept a special (with-early-config
> ...) form at the beginning of the ~/.emacs.

= I guess I would be fine with this, even though I think it's a little
hacky.

Best,
Radon
P.S. I notice you keep saying ~/.emacs. Is that out of
habit/convenience? I thought ~/.emacs was deprecated in favor of
~/.emacs.d/init.el.

--001a113f17d67eb21005578c6410--