8

I understand what autoload does for functions (register file to load when such function is called or its documentation string is retrieved). However, it's not clear how to use autoload facility in conjunction with variables and macros.

I have two questions:

  1. What happens when package has parameter, implemented as a variable that user can set, but it's not autoloaded? Should such variables be autoloaded? If not, it turns out that such variables do not exist, Lisp environment knows nothing about them, including their default values, until some autoloaded function from the package is used (typically after loading of configuration files), then if user sets them in his/her configuration file, it's like setting non-existing variable. If value of the variable is a non-empty list and user uses push or add-to-list to change its value, what exactly happens? Are default values lost?

  2. What happens when a macro is autoloaded? When should we autoload a macro?

5

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 were to change, the customized value should probably change too, yet the user won't be aware of it. If some package does have such variables, it may be best to alter it after the package has loaded, using eval-after-load.

Most customization variables will have a default value of nil, in which case you just set them using setq in your init file (or use the customization interface). Assuming the package uses defvar or defcustom to set the variable, as it should, it will not override your setting.

Autoloading macros: Set the fifth argument of autoload to achieve this. Like functions, this should be done if it's likely that you wish to use the macro without loading the package first – either explicitly, or implicitly by first invoking other autoloaded symbols from the package.

Addendum: As the OP pointed out in the comments, a magical ;;;###autoload comment will also copy a defvar (indeed, any elisp form) to the autoload file. See the Autoload section in the elisp manual for details.

  • So, variables that can be just setqed (i.e. it doesn't matter what values they had before) can have default specified in defvar or defcustom form, but in case of list that can be extended by user it's best to use eval-after-load right? Also, sometimes good defaults are good, even if they take form of a list ;-) – Mark Karpov Jul 13 '15 at 7:33
  • That's right. I would argue that if a common customization requires eval-after-load, it's a bug in the package implementation. Typically, eval-after-load should be used for bug fixes or highly unusual customizations. By the way, it may be better to use a hook if the package makes one available. – Harald Hanche-Olsen Jul 13 '15 at 8:12
  • The problem is that I wanted to have a variable that's bound to list of three elements (defaults). The defaults is what most users want, I'm sure. But if I go eval-after-load way, users still won't be able to remove elements from the list! This makes me wonder if I should abandon the defaults at all. – Mark Karpov Jul 13 '15 at 8:16
  • 1
    I don't agree that eval-after-load should be needed only for unusual situations. It's one of the standard tools in the deferred-loading toolkit. If people don't want to use such tools, they can require the library up front (which is indeed what newcomers are invariably recommended to do -- by the time they get around to thinking "I wish Emacs started a little faster", they've probably learned enough not to be scared off by the new syntax :) – phils Jul 13 '15 at 8:56
  • 1
    @Drew: Your point on using customize-set-variable rather than setq may be a good one. But I don't have the time now for the careful study required to improve my answer in this regard. If you think this is important, why don't you write your own answer? It will be more visible than this long comment thread. – Harald Hanche-Olsen Feb 1 '16 at 12:55

This site is temporarily in read only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .