History

Henrik Lissner d96a283b7f private/hlissner: don't track snippets directory (use +hlissner/install-snippets)		2017-02-20 13:40:26 -05:00
..
completion	Add modules/completion/ido	2017-02-20 00:26:08 -05:00
feature	feature/eval: make +repl:eval-region operators not move point	2017-02-20 00:44:38 -05:00
lang	lang/org: remove no-byte-compile flag	2017-02-20 13:18:59 -05:00
private/hlissner	private/hlissner: don't track snippets directory (use +hlissner/install-snippets)	2017-02-20 13:40:26 -05:00
tools	Add modules/tools/tmux	2017-02-20 00:26:08 -05:00
ui	doom-folded-face => +doom-folded-face	2017-02-20 00:26:48 -05:00
README.md	Update READMEs	2017-02-20 12:02:57 -05:00

README.md

Modules

Modules are made up of three (optional) parts:

A config.el file, automatically loaded when the module is loaded (through @doom or @require). It uses @def-package calls (thin wrappers around use-package) to configure packages.
A packages.el file filled with @package and @depends-on declarations. These are purely declarative macros. They populate doom-packages and doom-modules for the package management system.
Either an autoload.el file or autoload/*.el files, which are scanned by doom/reload-autoloads and lazily loaded.

The convention for extra config files is to prefix them with a plus (+git.el). These are not automatically loaded.

What modules aren't

Modules loosely take after Spacemacs' notion of layers, but are not meant to be interchangeable. Their purpose is almost purely organizational.

The only exception to this are completion modules. Other modules make no assumptions about which completion modules are enabled. If company isn't installed, company plugins will silently refuse to install, and their respective @def-package blocks will be ignored.