If you want to use require, you can only use the following:

(require 'foo)
(require 'bar)

But you can't do the following:

(require 'foo

Would it not be more easier and faster if require accepts the argument structure in the same way as setq does:

  (setq foo t
        bar t)

closed as primarily opinion-based by wasamasa, Drew, PythonNut, Kaushal Modi, Jordon Biondo Aug 6 '15 at 15:22

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    This doesn't seem opinion-based to me, though removing the "wouldn't this be easier" phrasing would help. I read the question as why require doesn't behave like setq, and the answer that @Drew and I both came up with is that require has additional features of which the OP was likely not aware. – glucas Aug 6 '15 at 15:47
  • 2
    Fair enough - though I'd say the detail about setq being considered a misfeature is a really interesting answer as well. :-) I still think the question of "why does require only accept a single package name rather than n names" is reasonable. But apparently the OP was not actually asking that, since the accepted answer is an answer to "how do I avoid repeating this code". The question should probably be revised accordingly. – glucas Aug 6 '15 at 15:50
  • 2
    setq and require behave differently because they are two totally unrelated functions. Also note that the "newly" added setq-local does not allow setting multiple variables, because the Emacs maintainer considers it a mistake that setq behaves that way (but has to keep it that way for backward compatibility). And most importantly please use require once for each feature. Don't use a loop, don't use a macro. There are tools that assume that features are always required using one require form per feature. – tarsius Aug 6 '15 at 16:17
  • 1
    The main reason I would strongly recommend against using dolist is that I see absolutely no benefit in replacing "needless duplication" with "a little bit of extra cognitive overhead". When I see a block of require forms, I immediately see what is going on and what features are being required. When I see a top-level dolist with a require as body, it takes me a bit of time to realize that, and then I wonder why that is being done. I then have to check whether we are looping over a constant (quoted) list of features or whether some function is being called to provide the list. – tarsius Aug 6 '15 at 22:07
  • 1
    Regarding the "tools that need (require 'feature)": I extract metadata from all packages on the Emacsmirror, including the required and provided features. Because loading all packages (and then asking Emacs what features are required and provided by a library) would be insecure (and in many cases would fail) I have to extract the features using text search. – tarsius Aug 6 '15 at 22:12

You can use dolist to avoid repetitive code if you like.

(dolist (pkg '(pkg1 pkg2 pkg3))
  (require pkg))

Above will be equivalent to:

(require 'pkg1)
(require 'pkg2)
(require 'pkg3)

The advantage is that you can also specify the identical arguments you might need to pass to a bunch of requires:

(dolist (pkg '(pkg1 pkg2 pkg3))
  (require pkg nil :noerror))

require already accepts additional arguments. In particular, you can do a "soft" require this way:

(require 'foo nil t) ; No error raised if library foo is not available

Nothing special would be gained by letting you do:

(require 'foo  nil nil
         'bar  nil nil
         'toto nil nil)

(You can easily write your own macro to do what you request, however.)


That might be more convenient in the simple case of just listing a bunch of features to load. Note however that require can take some optional arguments:

From the doc string (with some stuff elided):

(require FEATURE &optional FILENAME NOERROR)

If feature FEATURE is not loaded, load it from FILENAME...If FILENAME is omitted, the printname of FEATURE is used as the file name... If the optional third argument NOERROR is non-nil, then return nil if the file is not found instead of signaling an error...

Not the answer you're looking for? Browse other questions tagged or ask your own question.