[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Loading a package applies automatically to future sessions?

From: Tim Cross
Subject: Re: Loading a package applies automatically to future sessions?
Date: Mon, 5 Feb 2018 08:27:02 +1100

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.


On 5 February 2018 at 02:21, Clément Pit-Claudel <address@hidden> 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 just
> 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 installing
> 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 your path, so you can call the program from the command line.
* Python has .pth files that work essentially like Emacs autoloads.  These 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.




Tim Cross

reply via email to

[Prev in Thread] Current Thread [Next in Thread]