emenel/doomemacs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Update readmes

Browse source
This commit is contained in:
Henrik Lissner 2017-03-16 14:28:26 -04:00
parent f156f62479
commit ce3afd2a2a
3 changed files with 24 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

17
modules/README.md
View file

@ -3,7 +3,7 @@
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
(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
@ -13,15 +13,16 @@ Modules are made up of three (optional) parts:
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.
(`+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 are not
meant to be interchangeable. Their purpose is _almost_ purely
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 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.
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.