From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Loading a package applies automatically to future sessions? Date: Mon, 5 Feb 2018 08:27:02 +1100 Message-ID: References: <76b1fb81-54c0-c213-a542-dc7b9838c473@gmail.com> <2df2ff0a-6bbd-4d39-c830-ce2891909418@gmail.com> <0322c9de-6882-83f3-39ee-66bbb692579a@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113dd64c48126f0564699b64" X-Trace: blaine.gmane.org 1517779567 2400 195.159.176.226 (4 Feb 2018 21:26:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 4 Feb 2018 21:26:07 +0000 (UTC) Cc: Emacs developers To: =?UTF-8?Q?Cl=C3=A9ment_Pit=2DClaudel?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 04 22:26:02 2018 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 1eiRnL-00080h-1z for ged-emacs-devel@m.gmane.org; Sun, 04 Feb 2018 22:25:51 +0100 Original-Received: from localhost ([::1]:41715 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eiRpK-00032l-Hz for ged-emacs-devel@m.gmane.org; Sun, 04 Feb 2018 16:27:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35252) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eiRoY-00030Y-25 for emacs-devel@gnu.org; Sun, 04 Feb 2018 16:27:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eiRoW-0000N0-HC for emacs-devel@gnu.org; Sun, 04 Feb 2018 16:27:06 -0500 Original-Received: from mail-oi0-x22f.google.com ([2607:f8b0:4003:c06::22f]:37590) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eiRoW-0000MU-AX for emacs-devel@gnu.org; Sun, 04 Feb 2018 16:27:04 -0500 Original-Received: by mail-oi0-x22f.google.com with SMTP id t78so19867702oih.4 for ; Sun, 04 Feb 2018 13:27:03 -0800 (PST) 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=S0NNjgLXxWnB1LVwX2jQ0KwkNG3JSddLs9H+017OfHE=; b=S1zInc0vffdgTjhcFZURmMPjMARKTYun9HAvRM/+jIltitUAqLo8Du34NHJmaDzMjJ Ss5QaBu1vKLohu1jHkJsXgnSqRgOSpqe3KMtIFAZyrhSOvnOtVHB+DkJStm2FlbhstdU fuksOxchUuXY66e6yOHEfs3l/xQdZ+Bzq/IYB0zDc5lVaVueLD3aGqxnGmvqUOfi8MBK nQFYJfqMp0FHFueVobxuQ0Bj1hWsruX49dpZfiEPCkG7B0/U1yvdyLh6X4mchY6xnnm6 Oq5pymFe85cB1Lf60Pw/Gp9fyVS6egWs5ypbvd20knNoCtDpHY1XAjo2zIBIgDnCyuyG eNxA== 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=S0NNjgLXxWnB1LVwX2jQ0KwkNG3JSddLs9H+017OfHE=; b=tv2f4kWiyGcZSy/BaYMzm4ThJE1xRdPqz9pH02NDkHuwTzjT3+C0luwrq0WynBqLvZ QWURlvjaDyzWRcgGiPLiPU1RZ9Qba0ZBzsF0jjL4IKnMuee8xAQnilwrXWFKKIMG+A+T VELCxxTULds3Xoqe2womKBewG3kQcIdIT8k6Z5Ubr3ruBF/z0XMCtTOjsayPHWrpPBK2 vSk2bquRXL284PPQc3LN8lyJkdEDXNsafaw5HtFtafVtc2sJXy491qrDdZIa5iiNiwz4 t4DGRCjl+MF3NoBrGhKLlud473iQdfci1cDojtRFDOr4+DQN2aJ39GVn6cu7Wv+hv1cy TShA== X-Gm-Message-State: AKwxyteLlNDWmQm6EDiiKGnRjCRVGWqKzqucSYhKn2sr+FAjuKYBHDfG hjqJaobQ8w2C4zo/WB8n6f903+YCHyTSZNqKnWA= X-Google-Smtp-Source: AH8x225dma2hIak1/2ksXLh47sU0ntmSS2pVwQO5jJpKXI9f0Z51wg1pSKsiTIGV+hd763NT3gqwMsFlnF9jD+/dJCs= X-Received: by 10.202.245.201 with SMTP id t192mr19770109oih.295.1517779623087; Sun, 04 Feb 2018 13:27:03 -0800 (PST) Original-Received: by 10.168.183.198 with HTTP; Sun, 4 Feb 2018 13:27:02 -0800 (PST) In-Reply-To: <0322c9de-6882-83f3-39ee-66bbb692579a@gmail.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4003:c06::22f 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:222524 Archived-At: --001a113dd64c48126f0564699b64 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable While I think I can see what RMS is concerned about, I am not necessarily convinced the concern is significant enough to warrant implementation of additional user action that would be required in order to activate packages in future sessions. One of the great benefits of the ELPA system has been how much easier it has made it to add useful extensions and keep those extensions up-to-date without requiring the user to write any ELISP. While I personally don't find writing ELISP a challenge, many do - or at least shy away from it initially. Bottom line is that when you install most ELPA packages, the package will often install basic autoloads. This means that should you do something or execute one of the autoload commands, the package will load and run in future sessions. So, in effect, the answer to the original question is yes, packages are available and will be automatically loaded in future sessions if the user executes one of those autloaded functions. However, I'm not aware of any packages which setup hooks or add themselves to hooks so that the package is loaded without specific user action in future sessions (I have not tried all packages and it would certainly be possible for a package to do this, though it might be tricky to implement unless you edit the user's init file, which I don't think is normal for an elpa package). I feel the basic mechanism to prevent packages from being available in future sessions is to simply remove them. I actually think this is a good practice as it prevents people from building up large numbers of unused/unnecessary packages that only slow down updates. It also reduces the likelihood of unused packages conflicting with used packages and works towards a cleaner environment. Given that re-installing is also trivial, I don't think this is too much of a burden should there be a package you only need very rarely. Anyone who wants something more complex is of course free to implement such functionality themselves. Tim On 5 February 2018 at 02:21, Cl=C3=A9ment Pit-Claudel wrote: > > > There may be a misunderstanding. Emacs already works in (mostly) > the same way: Emacs' `require' is very close to Python's `import'. > > > > That's the behavior I'd expect a feature like this to have. > > > > > * Emacs has autoloads, small pieces of code from packages that are > run inconditionally. > > > > I do know about autoloads; I implemented them. > > I know that; but I'm writing to the entire list, and there may be other > readers who are less familiar with autoloads :) > > > The questions are (1) do a lot of these packages have autoloads, or jus= t > > a few, and (2) when do the autoloads get installed into Emacs. > > Most packages, AFAICT, make their main interactive entry points > autoloads. I think that is the right behavior. > > > If adding a package to the list for loading has the effect of installin= g > > its autploads in all future sessions, that results in behavior very > > different from the 'require' behavior, and behavior that doesn't match > > what I'd expect such a feature to have. > > > > Does Python have autoloads? I would expect not. > > Yes, in two senses: > > * Installing a package with 'pip' commonly installs small binaries in you= r > path, so you can call the program from the command line. > * Python has .pth files that work essentially like Emacs autoloads. Thes= e > aren't used very commonly. > > > Since the effect of calling an autoload function is to call 'require', > > it could be that lexical handling of 'require' will automatically > > clean up the way these autoloads are handled. > > The thing is, I don't a the problem with the way autoloads are currently > handled. seeWe just need to find a way to make processing autoloads > faster, and in fact Stefan has a solution for that, IIUC. > > The fact that installing a package installs its autoloads is desirable; > just like the fact that running 'apt-get install emacs' puts the emacs > binary on your path. > > I think lexical vs dynamic 'require' is a different issue. > > Cl=C3=A9ment. > > --=20 regards, Tim -- Tim Cross --001a113dd64c48126f0564699b64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While I think I can see what RMS is concerned about, I am = not necessarily convinced the concern is significant enough to warrant impl= ementation of additional user action that would be required in order to act= ivate packages in future sessions. One of the great benefits of the ELPA sy= stem has been how much easier it has made it to add useful extensions and k= eep those extensions up-to-date without requiring the user to write any ELI= SP. While I personally don't find writing ELISP a challenge, many do - = or at least shy away from it initially.=C2=A0

Bottom lin= e is that when you install most ELPA packages, the package will often insta= ll basic autoloads. This means that should you do something or execute one = of the autoload commands, the package will load and run in future sessions.= So, in effect, the answer to the original question is yes, packages are av= ailable and will be automatically loaded in future sessions if the user exe= cutes one of those autloaded functions. However, I'm not aware of any p= ackages which setup hooks or add themselves to hooks so that the package is= loaded without specific user action in future sessions (I have not tried a= ll packages and it would certainly be possible for a package to do this, th= ough it might be tricky to implement unless you edit the user's init fi= le, which I don't think is normal for an elpa package).=C2=A0

I feel the basic mechanism to prevent packages from being a= vailable in future sessions is to simply remove them. I actually think this= is a good practice as it prevents people from building up large numbers of= unused/unnecessary packages=C2=A0 that only slow down updates. It also red= uces the likelihood of unused packages conflicting with used packages and w= orks towards a cleaner environment.=C2=A0 Given that re-installing is also = trivial, I don't think this is too much of a burden should there be a p= ackage you only need very rarely.=C2=A0 Anyone who wants something more com= plex is of course free to implement such functionality themselves.

Tim





= On 5 February 2018 at 02:21, Cl=C3=A9ment Pit-Claudel <= ;cpitclaudel@gma= il.com> wrote:
>=C2=A0 =C2=A0> There may be a misunderstanding.=C2=A0 Emacs al= ready works in (mostly) the same way: Emacs' `require' is very clos= e to Python's `import'.
>
> That's the behavior I'd expect a feature like this to have. >
>=C2=A0 =C2=A0> * Emacs has autoloads, small pieces of code from pack= ages that are run inconditionally.
>
> I do know about autoloads; I implemented them.

I know that; but I'm writing to the entire list, and there may b= e other readers who are less familiar with autoloads :)

> The questions are (1) do a lot of these packages have autoloads, or ju= st
> a few, and (2) when do the autoloads get installed into Emacs.

Most packages, AFAICT, make their main interactive entry points auto= loads.=C2=A0 I think that is the right behavior.

> If adding a package to the list for loading has the effect of installi= ng
> its autploads in all future sessions, that results in behavior very > different from the 'require' behavior, and behavior that doesn= 't match
> what I'd expect such a feature to have.
>
> Does Python have autoloads?=C2=A0 I would expect not.

Yes, in two senses:

* Installing a package with 'pip' commonly installs small binaries = in your path, so you can call the program from the command line.
* Python has .pth files that work essentially like Emacs autoloads.=C2=A0 T= hese aren't used very commonly.

> Since the effect of calling an autoload function is to call 'requi= re',
> it could be that lexical handling of 'require' will automatica= lly
> clean up the way these autoloads are handled.

The thing is, I don't a the problem with the way autoloads are c= urrently handled.=C2=A0 seeWe just need to find a way to make processing au= toloads faster, and in fact Stefan has a solution for that, IIUC.

The fact that installing a package installs its autoloads is desirable; jus= t like the fact that running 'apt-get install emacs' puts the emacs= binary on your path.

I think lexical vs dynamic 'require' is a different issue.

Cl=C3=A9ment.




--
regards,

Tim

--
Tim Cross

--001a113dd64c48126f0564699b64--