autoload is not a substitute for require. Typically require is used to make sure that a certain file is loaded. autoload on the other hand gives Emacs a hint in which file to find a given function without loading the file right away. Only when the autoloaded function is called is the corresponding file loaded.
Basically with autoload you can delay the ...
One of the design choices in package.el was to try and make things "simple". Part of this is that package-initialize searches for all the packages that are installed, then tries to figure out which ones of those should be activated (according to pinning, and recency of versions in case where multiple versions of the same package are available), then loads ...
The correct solution (IMO) is to use a package manager which has explicit support for this use case. This would be straight.el, which I wrote for this purpose.
You can read verbose documentation, including comparisons to other package managers, in the README, so I'll stick to how you can use straight.el to solve your specific problem.
Place your repository ...
The problem you describe about package-initialize taking so much time to load is a well known problem. It is also one of the problems that some emacs frameworks try to solve by loading the autoloads manually.
I see two solutions to your problem.
Write (or extract from a framework) the functionality to set the paths and load the autoloads of the packages ...
This has been discussed more than once on email@example.com.
Here is one such thread, from 2016.
And here is something from Stefan, who dislikes such autoloading, from 2014.
Likewise, Glenn, in this 2010 thread.
And Stefan again, in 2009.
And here is an earlier 2009 thread about it.
There are many more such discussions, going back further.
One reason ...
The function magit-version is not autoloaded in magit.el. If you look at the source, you will notice that that function definition is not preceded by ;;;###autoload (as of Magit version 20150921.1712).
If you eval magit.el file, you will see that M-x magit-version would then be available.
How to get M-x magit-version working?
There are a couple of ways to ...
Autoloading only applies to the function value slot of a symbol. In particular, there is no such thing as autoloading a variable.
It is probably bad form for a package to contain variables for user customization whose default value is a nonempty list, precisely because it becomes difficult to customize the variable in that case. Worse, if the default value ...
I think this should do what you want:
(add-hook 'some-mode 'package-x-function))
The :commands directive will generate an autoload for package-x-function, and the :init directive will immediately add it to the hook. Because :commands implies :defer, the package won't be loaded immediately. When the ...
Consider using John Wiegley's use-package if you really care about startup time that much. use-package provides built-in support for lazy/deferred loading.
Better yet, don't constantly restart your Emacs. The best way to avoid constantly restarting is to run an Emacs daemon; then you can create as many frames (both GUI and terminal) as you like that will ...
If I know for a fact that package X has "built-in" autoloads (i.e. autoloads defined by the package author), then can I simply set :defer t and rely on those to load the package at the appropriate time?
Yes, that's exactly what that means. Similarly, you can also use :defer t in place of something like :mode or :interpreter if the package already handles ...
You don't need autoload here. Just put (require 'a-lib) and (require 'b-lib) inside function c itself (assuming a-lib and b-lib are the libraries that define functions a and b, respectively).
That is, let function c load the libraries its code needs. They will be loaded only the first time (and only if they have not already been loaded).
(defun c ()
Short answer: Don't edit custom-set-variables form by hand.
Tramp must be loaded for custom-set-variables to work. Either load tramp before custom-set-variables:
Or see Michael's answer for a way to tell customize to load tramp first. Note that using M-...
In terms of Emacs initialization, don't make either choice. GitHub user jwiegley has the excellent use-package declaration macro, that will require or autoload a package as determined by need. Best used to defer the loading of packages that can be loaded on-demand.
You discovered most of the answer yourself. When you install clojure-mode, you also get a file clojure-mode-autoloads.el. That file besides adding the entries you mentioned to auto-mode-alist, also defines autoloads for the functions clojure-mode, clojurec-mode, etc.
Once the autoload file has been loaded (which normally package-initialize does on start up),...
I do the following on Linux:
I setup a local melpa repository by cloning melpa.
I modify the recipes I want to point to my local packages. The following is local-melpa/recipies/ace-window
Then from local-mepla type make all or make recipies/ace-window to build the package(s) ...
Maybe I am missing something, but the linked mdi.el file does not define the function mdi-insert. Its main entry-point is the autoloaded function mdi.
Either way, if adding :demand t to the mdi use-package form results in the desired behaviour, this means that the definitions in mdi.el being used aren't being successfully autoloaded. Note that adding an ...
I don't think you should run into any problems. I use :bind for commands that are already autoloaded (note that :bind implicitly generates autoloads, in the same way as :commands), and haven't run into any problems. And if you're using :commands and not :bind and you run into problems because of this, you should be able to solve them just by dropping the :...
If you want a certain feature to be loaded and available directly when your Emacs has started, use require, otherwise use autoload. I personally value startup time much (I actually restart Emacs a couple of times per week, sometimes several times per day), so I accept that it will take a little bit of time when Emacs autoloads a certain function when I need ...
Responding to your last comment, asking about the let*. Putting this into an answer so the doc-string can be clear.
The let* sexp is simply evaluated when the defcustom is read (e.g. the file is loaded), and its return value is used as the initial value of the user option (variable). C-h f defcustom tells you that. It says this about the second argument to ...
byte-compile-file comes from bytecomp.el which (require 'cl-lib), thus cl-lib is always already loaded before any byte compilation.
The info manual does also not contain any information about register-definition-prefixes.
Might it be that that command causes the autoloading at byte-compilation?
According to my understanding, that's a feature introduced ...
Fascinating. I can exactly reproduce what you're running in to if I try to use the customization interface. However! I can successfully change the value of tramp-remote-path by skipping the customization interface, either of two different ways.
First, tramp expects tramp-remote-path to be a list, so my inclination is to do this (in my init.el):
I'd recommend two things to speedup startup:
Merge your many init files into a single large file.
Look at the content of your init files and try to make sure that they don't require or load but instead, they should just use setq, add-hook, and eval-after-load.
Currently, autoloading a function is done all in C code with fairly few Lisp-visible effects (other than the loading itself). As you have discovered advising load may not catch it, for example.
I can see two ways to attack the problem:
use hooks (e.g. after-load-functions) and advice to detect loads,
and then use the backtrace mechanism to try and ...
tramp.el must be loaded indeed when a Tramp user option shall be set. The proper way to do this is
'(tramp-remote-path (quote (tramp-own-remote-path)) nil (tramp)))
Maybe this shall be described in the Tramp manual.
If you have replaced an already installed package with a different version, and all you are missing is the autoloads file, you can use package-generate-autoloads to generate it:
(package-generate-autoloads "async" "~/.emacs.d/elpa/async-1.9.3/")
I found it easier then using update-directory-autotools when I need to downgrade a package to an earlier version....
Don't make the advice conditional, but only its effect:
(defadvice something (before fix-something enable)
;;; do stuff
Tho of course I'd use advice-add instead:
(advice-add 'something :before
;;; do stuff
Pieces of advice can be installed before ...
What can I use as the :init form to load the autoloads as package.el would?
(with-demoted-errors "Error loading autoloads: %s"
(load "~/path/to/PACKAGE/PACKAGE-autoloads" nil t))
Refer to the function package--activate-autoloads-and-load-path.
I'm assuming package.el loads the autoloads for every directory in load-path upon activation and before each ...