what is the difference between requiring a package and activating it?

Like difference between (require 'origami) and (origami-mode 1) Why can't you directly do the latter? I noticed it works even without requiring the package. I see that any installed package can be activated in a buffer through M-x without requiring it or you can put this in init.el. What is the point of requiring a package? I thought it's similar to import module in python, but it doesn't seem to be. Importing is all that is required in python, no activating.

When a function is [autoloaded](https://www.gnu.org/software/emacs/manual/html_node/elisp/Autoload.html) (the autoload itself possibly loaded from a file), the first call to the function loads the actual definition. On the other hand, [`require`ing a feature](https://www.gnu.org/software/emacs/manual/html_node/elisp/Named-Features.html) is similar to importing a module in some languages. If neither the autoload nor the actual definition is loaded, then you get a `void-function` error. Edit: And enabling a minor mode is not “activating” a package. See [the Emacs manual](https://www.gnu.org/software/emacs/manual/html_node/emacs/Minor-Modes.html).

So when a package is installed through M-x "package-install" , the function definition is loaded when a call to function is made. Emacs knows where to find the module if needed. Then what is the purpose of require? Do you only need require when you have manually downloaded the package? But even then we add the folder package is located in to the load path. Then what is the point of requiring?

Your questions could’ve been answered by the manual, but I’ll give a few hints. 1. Certain package managers automatically generate and `require` autoload files. This only works for definitions with a so-called “autoload cookie.” Again, see [the Elisp manual](https://www.gnu.org/software/emacs/manual/html_node/elisp/Autoload.html). 2. `load-path` is an independent concept. It’s related to [library searching](https://www.gnu.org/software/emacs/manual/html_node/elisp/Library-Search.html), i.e. where to search files for `load` or `require`. 3. `require` is for explicitly [requiring a feature](https://www.gnu.org/software/emacs/manual/html_node/elisp/Named-Features.html), which is usually but not necessarily per-file. Autoload files can be loaded this way, so can normal Elisp files. More often, it’s used in Elisp programming to ensure that definitions are available.

And now add `provide` to the list of concepts to learn about this weekend 🤗

Installing package: downloading the code to your machine, this is what “package-install foo” does. Requiring package: loading its code, but not executing any of it, this is what “require foo” does Activating: actual execution of the code, often on a per-major-mode basis, this is what “foo-mode” does There’s also “use-package foo”, which performs install + require automatically.

**Part 1: require** Let's say you have file origami.el on your hard disk. For the sake of learning, pretend you are not using the package manager as it automatically does a bunch of autoload file magic. origami.el contains a function **origami-mode** in it. If you attempt to call it: (origami-mode 1) ;; error! you will get an error. Because it's not loaded into Emacs yet, it's just sitting in the text file. You need to do 2 things to get this into Emacs. ;; 1. in your init file, add origami.el to the **load-path**. ;; load-path is a list of folders Emacs searches for lisp files. (add-to-list 'load-path "/folder/where/origami/lives") ;; 2. require the "feature". ;; By convention the feature-name usually matches the filename. ;; The feature name is set with 1 line of code (provide 'origami) in origami.el ;; NOTE: "require" is a fancy version of "load", it just keeps track of what you already ;; loaded so you don't load the same thing redundantly. (require 'origami) Now origami.el is loaded. You can successfully call functions now. (origami-mode 1) ;; success! **Part 2: autoloads** Using require works fine. However it loads the ENTIRE file and all functions into memory. This slows down Emacs startup time. If the lisp file is huge and/or you require thousands of lisp libraries then it can add minutes to your start up time!!!! What if you could avoid loading a huge lisp file until you actually need to call one of it's functions? This is what autoloads are for. They are light-weight "dummy" place holder functions that you can declare in your init file. The moment you call the "dummy" function, the lisp file is loaded and the "dummy" autoloads are replaced with the "real" functions from the lisp file. You set up an autoload like this ;; 1. as always make sure Emacs knows about the folder where the lisp file lives. (add-to-list 'load-path "/folder/where/origami/lives") ;; 2. in your init file, create an autoloads for each "entry point" function. ;; You don't need to create autoloads for all functions, just the ones you call first. ;; For many lisp libraries this will be the function that turns on the mode. (autoload #'origami-mode "origami" nil t) Now you have a fast Emacs start up! origami.el is not loaded, but has a light-weight dummy autoload set up. until you call: ;; turn on origami mode via the dummy autoload. It will immediately load origami.el and replace the dummy ;; autoload with the real function. (origami-mode 1) The package manager does this autoload stuff for you. In origami.el several functions are flagged with a magic comment ;;;###autoload This comment lets the package manager know which functions it should create autoloads for. The package manager creates a special autoload file and loads it on start up. An excessive amount of autoload files can be slow in their own right, but much faster than loading all the lisp files.

Oh thanks a lot for the lengthy response. But shouldn't requiring be obsolete when using a package manageer? I notice most of my packages work fine even after removing (require 'origami), lines like that. So if an elisp file is in the load path, all of it will be loaded if I don't specify any autoloads? Also I noticed I still have to load the file explicitly even though it was in my load path. I wrote a file called own-functions.el (placed all self written functions in it) and then put it in the load path. I still had to do this (load own-functions) Lastly, why do you need to "require" a feature when already entire file is loaded? why (require origami) after (load 'origami)

> But shouldn't requiring be obsolete when using a package manager? No. Require may still be preferable over autoloads. You pay the price of loading a lisp file no matter what. It's just a matter of **when**. With autoloads your init time is faster, but then you experience a little delay when that package loads in the future. If it's something you always use then you might prefer paying the price of loading it when Emacs is starting up. Instead of experiencing a small lag later while you are trying to work. The basic rule is is this. Rarely used package? -> autoload. Commonly used package? -> require. > So if an elisp file is in the load path, all of it will be loaded if I don't specify any autoloads? No. Assuming no autoloads are set up you must (require 'origami) before before you can call any functions. The load-path just makes it so (require 'origami) knows where to look for files. > Also I noticed I still have to load the file explicitly even though it was in my load path. Yes that is expected. The load-path doesn't do any automatic magic. It's simply a list of folders that (require 'feature) searches over. > Lastly, why do you need to "require" a feature when already entire file is loaded? why (require origami) after (load 'origami) You don't. "require" and "load" do the same thing. So calling one after the other makes no sense. You should basically never use "load". Pretend it does not exist. Load is something an elisp hacker might use when they want to hard-force a file to load again. Require has an extra little check to "do nothing" if it detects the library is already loaded. Usually you should prefer "require" as it protects you from accidentally loading the same library twice. For library authors require is NEEDED so they can require shared libraries without triggering a redundant load causing unnecessary slowdown.

Oh thank you, this is the best answer so far.

One last question though, sorry. I have evil-org-mode installed through package manager. I manually turn it on whenever I need it usinng M-x evil-org-mode. Now I want this to be always available. So, first of all I don't need to require it as I already have autoloads for it through package manager. So when I add (evil-org-mode 1) in the init.el, the autoloads call the real functions and the entire lisp file is loaded into emacs, reducing startup time. The same things happens when I do require regarding loading and start up time, but require doesn't "activate" or make my functions available until I do (evil-org-mode 1) So I am better off just doing (evil-org-mode 1) instead of requiring it first and then doing (evil-org-mode 1). I guess one way I can take advantage of this is do (evil-org-mode 1) only for certain filetypes, so that this activation function is run only when certain conditions are met. So it won't be always loaded like it will be with require. I don't know how to do this yet. Are hooks the same thing?

> So when I add (evil-org-mode 1) in the init.el, the autoloads call the real functions and the entire lisp file is loaded Correct. > reducing startup time. No. Start up time is **not** reduced in this case. You call (evil-org-mode 1) in init.el so the autoload will load the lisp file. You pay the price during startup. Nothing wrong with that, you have to load lisp files to use the functions. You must load lisp files via some mechanism. Whether that mechanism is (require) or autoloads. Autoloads give flexibility to delay the load, but if you invoke the autoload during startup..... you pay the price at startup. > but require doesn't "activate" or make my functions available until I do (evil-org-mode 1) Nope. After you (require) a lisp file, all functions defined in that file are available to be called. Unless you are specifically talking about "turning on the mode". Yes require does not "turn on" the mode, just loads all the functions into memory. > So I am better off just doing (evil-org-mode 1) instead of requiring it first and then doing (evil-org-mode 1). It's the same thing in this case. One is not "better". Both cause a load of the lisp file during startup. > I guess one way I can take advantage of this is do (evil-org-mode 1) only for certain filetypes, so that this activation function is run only when certain conditions are met. So it won't be always loaded like it will be with require. I don't know how to do this yet. Are hooks the same thing? Yes hooks are a how you turn on "helper" modes whenever some "other" mode runs. When using autoloads, hooks are a good way to delay loading a mode until you need it. (add-hook 'org-mode-hook #'evil-org-mode)