:defer now supports a hook, a cons cell with (SYMBOL . INTEGER) where
SYMBOL is a hook and INTEGER is a number of idle seconds before the
package is autoloaded, or just the integer (as per the default behavior
of :defer).
Also fixes an issue where switch-buffer-deffered packages (like
smartparens) wouldn't load.
+ New `input` and `buffer` support for :defer in def-package! can now
defer packages until the first command invoked after startup or first
interactive buffer switch, respectively
+ Exploit these new :defer techniques to lazy-load many core packages,
netting Doom a 20-30% decrease in startup time
+ Various userland macros (like package!, def-package-hook!, packages!,
and disable-packages!) will now throw an error if used incorrectly
(i.e. outside of their intended files; e.g. package! should be used in
packages.el files)
+ Removed support for multiple/nested doom! calls. There should only be
THE ONE in ~/.doom.d/init.el (or ~/.config/doom/init.el)
+ Fix an issue where load-path and auto-mode-list modifications would
not persist because doom-packages-file was cached too late.
+ Added package-activated-list to cached variables in
doom-packages-file, thus we no longer need custom-file.
+ Load Doom core files from doom-initialize. Now doom-initialize can be
called from state-dependent non-interactive functions, instead of
reloading core/core.el, which was clumsy
+ Removed the doom-post-init-hook hook. There was no reason for it to
exist when doom-init-hook can simply be appended to
There was no way to customize doom-fringe-size. Better to customize
fringes by using fringe-mode, {left,right}-fringe-width or
set-window-fringes directly.
Switch-window hooks would fire too frequently; like when switching to
the same window, clicking in windows, or from the minibuffer (e.g.
during ivy sessions).
cycle-real-buffers was a tidbit of complexity that was never necessary
in the first place. This functionality was already available in the form
of the frame buffer-predicate parameter, which controls where functions
like next-buffer and other-buffer can land you.
The only thing I have to do myself, is check for the condition where
there are no more real buffers left to switch to, and in that case send
you to the fallback-buffer.
doom/{next,previous}-buffer was implemented so that these commands could
skip over unreal buffers, and land us on either a real one or the
dashboard. Using the frame's buffer-predicate parameter accomplishes
exactly this, natively.
Our kill-this-buffer advice, which tries to ensure the user will always
land on a real buffer after killing another, would prematurely jump to
the dashboard even though there were other available, real buffers.
Also fixes an issue where kill-this-buffer would get stuck switching
between the last buffers (because they aren't killed if they're visible
in other windows). If the only buffers left are visible in other
windows, it will now switch to the fallback buffer (dashboard or
scratch).
Phases out dependence on the doom-kill-buffer workflow, which ensured
the user would always land on a real buffer (or the fallback buffer)
after killing a buffer. This required all quit-window, kill-this-buffer
and various buffer-killing commands be advised or remapped. There was no
need, kill-buffer-query-functions is better.
Also introduces a new hook: doom-init-theme-hook. doom-init-ui-hook
still exists, but is used for UI initialization (surprise), while theme
hooks should be moved over.
The "current" window is forgotten by the time
doom|protect-visible-buffers runs, so use get-buffer-window (native
C function) to detect if another window housing this buffer exists.
Protecting buffers that were visible in other windows (burying them
instead) is not the responsibility of doom-kill-buffer. This is a job
for kill-buffer-query-functions, hence doom|protect-visible-buffers.
I am removing settings for core configuration to reduce "magic" in Doom.
set! is meant for cross-configuring modules that may or may not be
enabled. There should be no such concern for configuring Doom core.
From now on, change your fonts with:
(setq doom-font (font-spec :family "Fira Mono" :size 12)
doom-variable-pitch-font (font-spec :family "Fira Sans")
doom-unicode-font (font-spec :family "DejaVu Sans Mono")
doom-big-font (font-spec :family "Fira Mono" :size 19))
+ Add relative line number support (see doom-line-numbers-style)
+ Update doom/toggle-line-numbers
+ New hook functions: doom|enable-line-numbers,
doom|disable-line-numbers
Addresses #156
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
+ Add doom-init-hook and doom-post-init-hook to simplify Emacs init
hooks into less ambiguous ones.
+ Attach former after-init-hook and emacs-startup-hook hooks to new doom
init hooks.
+ Vastly improves daemon and tty support: preventing incorrect colors
from bleeding across face class barriers, and into GUI Emacs and vice
versa, when spawned with emacsclient.
+ Fix persp-mode breaking Emacs daemon, and ensuring that initialization
is done properly in terminal Emacs (and emacsclient frames).
