There are some subtle issues with using the unicode, which depends
largely on the font you use. It is also slightly faster to use a space.
If you use whitespace-mode's space-mark feature, then change this to
?\u2002.
Addresses #109
WARNING: THIS IS A BREAKING CHANGE FOR THEME/FONT/NLINUM CUSTOMIZATIONS.
This change was motivated by the need to decouple theme and font loading
from the ui/doom module.
Now, it is doom-core's purview. Theme and fonts are loaded after
initfiles are read (attached to the doom-init-ui-hook hook), giving
other modules (especially private ones) a chance to change the theme or
fonts.
+ Refactor core-ui.el
+ New init hook: doom-init-ui-hook
+ Decouple theme/font loading from ui/doom
+ Load modelines are doom-init-ui-hook
+ New theme/font variables (replaces old ui/doom variables)
+ doom-theme
+ doom-font
+ doom-variable-pitch-font
+ doom-unicode-font
+ Change nlinum variables
+ doom-line-number-lpad
+ doom-line-number-rpad
+ doom-line-number-pad-char
Addresses #117
A wrong-type-argument: symbolp error occurs when core files are
byte-compiled and the expanded message!/format! macros are trying to
cl-flet-alias 'color to doom-ansi-apply (which hasn't been loaded yet).
doom-initialize-packages re-initializes certain important variables,
like gc-cons-threshold (which causes intermittent freezing when set too
high), without resetting them to sensible defaults. This ensures those
variable are reset afterwards.
It would reload all files; which is harmless, but does unnecessarily
inflate variables that get push-ed or nconc-ed to. It's best to compile
from the command line.
set! used to aggressively evaluate its arguments (at expansion-time),
even if placed inside an after! block. This causes unavoidable errors if
those arguments use functions/variables that don't exist yet.
Fixes#112
