- Code guidelines
- Key bindings conventions
- Writing documentation
Function names follow these conventions:
spacemacs/xxx
is an interactive function calledxxx
spacemacs//xxx
is a private function calledxxx
(implementation details)spacemacs|xxx
is a macro calledxxx
Variables follow these conventions:
spacemacs-xxx
is a variablespacemacs--xxx
is a private variable (implementation details)
A package is initialized in a function with name <layer>/init-xxx
where:
<layer>
is the layer namexxx
is the package name
- Always use
progn
when a code block requires multiple lines for:init
or:config
keywords. - If there is only one line of code then try to keep
:init
or:config
keywords on the same line. - Don’t nest multiple
use-package
calls unless you have a very good reason to do it.
SPC o
and SPC m o
must not be used by any layer. They are reserved for the
user.
SPC m
is reserved for the current major mode. Three keys bindings are not an
issue (ie. SPC m h d
) since SPC m
can be accessed via ,
.
Transient states are generally put behind the dot key .
, for instance the
windows manipulation transient state in SPC w .
.
When it is not possible to use the .
(like in helm
buffers) transient states
should be enabled with M-SPC
and s-M-SPC
. We need the latter bindings on
macOS since M-SPC
is used by the OS for spotlight.
It is recommended to make sure that q
allows to leave the transient-state.
Evilifying a buffer is to set the evilified state
as the default
state for the major mode of the buffer.
Except for eww-mode
buffers, all buffers with major-modes derived from
special-mode
are evilified by default. To exclude buffers of such major-modes
from getting evilified, add a regexp to evil-buffer-regexps
.
The evilified state
is derived from the emacs state
and modify the
map to:
- add
hjkl
navigation - add scrolling feature on
C-f
,C-b
,C-d
andC-u
G
andgg
to go to the end and beginning of the buffer- add jump back-forward in history on
C-o
andC-i
respectively - add incremental search with
/
,n
andN
- enabling
evil-ex
on:
- add
visual state
andvisual line state
onv
andV
- add yank on
y
in visual state only - activate evil-leader key on
SPC
Setting the evilified state
to a mode is done by calling the macro
evilified-state-evilify-map
.
Evilification rebinds shadowed key bindings according to the following rules:
- alphabetic key bindings:
x
->X
->C-x
->C-X
SPC
->'
/
->\
:
->|
C-g
cannot be shadowed
If a key binding cannot be remapped then it is ignored and a warning message
is displayed in *Messages*
.
To be consistent with the Vim way, n
and N
are favored over Emacs n
and
p
.
Ideally a transient-state should be provided to smooth the navigation experience. A transient-state allows to repeat key bindings without entering each time the prefix commands. More info on transient-states in the documentation.
The prefix for going to something is SPC m g
.
Key | Description |
---|---|
m g a | go to alternate file (i.e. .h <--> .cpp ) |
m g b | go back to previous location (before last jump) |
m g g | go to things under point |
m g G | go to things under point in other window |
m g i | go to imports |
m g t | go to corresponding test file if any |
m g u | go/find usage of thing under point |
Navigation in buffers like Helm
and ido
which are in insert state
should be performed with C-j
and C-k
bindings for vertical movements.
Key | Description |
---|---|
C-j | go down |
C-k | go up |
Confirming and aborting actions which are bound to C-c C-c
and C-c C-k
in raw Emacs are mirrored in Spacemacs to:
Key | Description |
---|---|
SPC m , and SPC m c | Valid/Confirm the message |
SPC m a and SPC m k | Abort/Discard the message |
Some example of these modes are magit
commit messages, message-mode
for
mails or org-mode
notes.
Live evaluation of code is under the prefix SPC m e
.
Key | Description |
---|---|
m e $ | put point at the end of the line and evaluate |
m e b | evaluate buffer |
m e e | evaluate last expression |
m e f | evaluate function |
m e l | evaluate line |
m e r | evaluate region |
A lot of languages can interact with a REPL. To help keeping a consistent behavior between those languages the following conventions should be followed:
SPC m s
is the prefix for sending code. This allows fast interaction with the REPL whenever it is possible- lower case key bindings keep the focus on the current buffer
- upper case key bindings move the focus to the REPL buffer
Key | Description |
---|---|
m s b | send buffer |
m s B | send buffer and switch to REPL |
m s d | first key to send buffer and switch to REPL to debug (step) |
m s D | second key to send buffer and switch to REPL to debug (step) |
m s f | send function |
m s F | send function and switch to REPL |
m s i | start/switch to REPL inferior process |
m s l | send line |
m s L | send line and switch to REPL |
m s r | send region |
m s R | send region and switch to REPL |
Note: we don’t distinguish between the file and the buffer.
History navigation in shells or REPLs buffers should be bound as well to
C-j
and C-k
.
Key | Description |
---|---|
C-j | next item in history |
C-k | previous item in history |
C-l | clear screen |
C-r | search backward in history |
The base prefix for major mode specific compilation is SPC m c
.
Key binding | Description |
---|---|
m c b | compile buffer |
m c c | compile |
m c C | clean |
m c r | clean and compile |
Note: we don’t distinguish between the file and the buffer. We can implement an auto-save of the buffer before compiling the buffer.
The base prefix for debugging commands is SPC m d
.
Key binding | Description |
---|---|
m d a | abandon current process |
m d b | toggle a breakpoint |
m d B | clear all breakpoints |
m d c | continue |
m d d | start debug session |
m d i | step in |
m d l | local variables |
m d o | step out |
m d r | run |
m d s | next step |
m d v | inspect value at point |
Notes:
- Ideally a transient-state for breakpoint navigation should be provided.
- If there is no toggle breakpoint function, then it should be implemented at the spacemacs level and ideally the function should be proposed as a patch upstream (major mode repository).
Management of errors should be put under SPC m E
.
Key binding | Description |
---|---|
m E e | fix error around point |
m E l | show errors |
m E L | show errors and jump to errors list |
For layers supporting markup languages please follow the following keybindings whenever applicable.
All header functionality should be grouped under SPC m h
Key binding | Description |
---|---|
m h i | Insert a header |
m h I | Insert a header alternative method (if existing) |
m h 1..10 | Insert a header of level 1..10 (if possible) |
Insertion of common elements like links or footnotes should be grouped
under SPC m i
Key binding | Description |
---|---|
m i f | Insert footnote |
m i i | Insert image |
m i l | Insert link |
m i u | Insert url |
m i w | Insert wiki-link |
Manipulation of text regions should be grouped under SPC m x
Key binding | Description |
---|---|
m x b | Make region bold |
m x c | Make region code |
m x i | Make region italic |
m x q | Quote a region |
m x r | Remove formatting from region |
m x s | Make region strike-through |
m x u | Make region underlined |
m x v | Make region verbatim |
In normal mode Vim style movement should be enabled with these key bindings:
Key binding | Description |
---|---|
g h | Move up one level in headings |
g j | Move to next heading on same level |
g k | Move to previous heading on same level |
g l | Move down one level in headings |
Promotion, demotion and movement of headings or list elements (whatever is possible) should be enabled with the following keys when in Vim style or Hybrid with hjkl movements enabled:
Key binding | Description |
---|---|
M-h | Promote heading by one level |
M-j | Move element down |
M-k | Move element up |
M-l | Demote heading by one level |
In all editing styles promotion and demotion can be done with the following keys:
Key binding | Description |
---|---|
M-down | Move element down |
M-left | Promote heading by one level |
M-right | Demote heading by one level |
M-up | Move element up |
If table specific commands are available the they are grouped under the
SPC m t
group.
A lot of languages have their own test frameworks. These frameworks share common actions that we can unite under the same key bindings:
SPC m t
is the prefix for test execution.SPC m t g
is the prefix for test generation.SPC m t X
is used to executeSPC m t x
but in debug mode (if supported).
Key | Description |
---|---|
m t a | execute all the tests of the current project |
m t A | execute all the tests of the current project in debug |
m t b | execute all the tests of the current buffer |
m t B | execute all the tests of the current buffer in debug |
m t l | execute the last executed test again |
m t t | execute the current test (thing at point, function) |
m t T | execute the current test in debug (thing at point, function) |
Note: we don’t distinguish between the file and the buffer. We can implement an auto-save of the buffer before executing the tests of buffer.
Key | Description |
---|---|
m t m | execute the tests of the current module |
m t M | execute the tests of the current module in debug |
m t s | execute the tests of the current suite |
m t S | execute the tests of the current suite in debug |
Note that there are overlaps, depending on the language we will choose one or more bindings for the same thing
- Global toggles are under
SPC t
,SPC T
andSPC C-t
- Major mode toggles are only under
SPC m T
Refactoring prefix is SPC m r
.
When import
management is supported the following key bindings should be used:
Key binding | Description |
---|---|
m i i | add import for symbol around point |
m i f | fix/format imports |
m g i | go to imports |
Major-mode code formatting is under prefix SPC m =
.
Key binding | Description |
---|---|
m = = | format thing under point |
m = b | format current buffer |
m = f | format current function |
Web frameworks key bindings should go under SPC m f
.
The base prefix for help commands is SPC m h
. Documentation is considered
as an help command.
Key | Description |
---|---|
m h h | documentation of thing under point |
m h r | documentation of selected region |
Spacemacs provides an example layer README.org
file in
~/.emacs.d/core/templates/README.org.template
.
- Spacemacs tries to keep the documentation consistent between all layers by
providing some rules for spacing:
- After each header, you should not add an empty line
- Exception: If the first item under the header is a table, add an empty line after it
- At the end of each header node, there should be an empty line
- Note: Many layer
READMEs
do not follow this convention yet. Please fix them if you can.
- After each header, you should not add an empty line
- To keep things readable only mention the prefix
SPC
when documenting key bindings, you don’t need to mentionM-m
.