History

Henrik Lissner f5ce4d40b7 lang/python: fix pip bootstrap		2017-03-24 15:02:40 -04:00
..
app	app/write: remove doom-buffer-mode (buggy)	2017-03-09 00:36:38 -05:00
completion	Add modules/feature/jump (WIP)	2017-03-15 22:59:49 -04:00
feature	feature/snippets: clean up yas-keymap bindings	2017-03-23 15:48:48 -04:00
lang	lang/python: fix pip bootstrap	2017-03-24 15:02:40 -04:00
private	General comment + README cleanup	2017-03-20 04:24:10 -04:00
tools	Move tools/restclient => lang/rest	2017-03-17 23:40:05 -04:00
ui	ui/doom: remove doom/blink-cursor in focus-in-hook	2017-03-23 00:29:44 -04:00
README.md	Update readmes	2017-03-16 14:28:26 -04: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 must be manually loaded using load! from a module's configuration.

What modules aren't

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

The only exception 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.