- Halves LOC
- Adopts functional paradigm where possible.
- Reduces the filesize of autoloads files by ~10-20%
- Speeds up autoloads generation by ~20%
-f is necessary when there are changes to your system that Doom needs to
pick up when running 'doom refresh'. It won't do anything if your doom
dotfiles haven't visibly changed, which won't be the case if you are
installing, say, mu4e or vterm, through your system package manager.
What was initially a time-saving mechanic has become a trap for
beginners, so I've made -f its default behavior and its previous
behavior opt-in with the -n / --if-necessary switches.
Highlights:
- 'doom purge' now purges builds, elpa packages, and repos by default.
Regrafting repos is now opt-in with the -g/--regraft switches.
Negation flags have been added for elpa/repos: -e/--no-elpa and
-r/--no-repos.
- Removed 'doom rebuild' (it is now just 'doom build' or 'doom b').
- Removed 'doom build's -f flag, this is now the default. Added the -r
flag instead, which only builds packages that need rebuilding.
- 'doom update' now updates packages synchronously, but produces more
informative output about the updating process.
- Straight can now prompt in batch mode, which resolves a lot of issues
with 'doom update' (and 'doom upgrade') freezing indefinitely or
throwing repo branch errors.
- 'bin/doom's switches are now positional. Switches aimed at `bin/doom`
must precede any subcommands. e.g.
Do: 'doom -yd upgrade'
Don't do: 'doom upgrade -yd'
- Moved 'doom doctor' from bin/doom-doctor to core/cli/doctor, and
integrated core/doctor.el into it, as to avoid naming conflicts
between it and Emacs doctor.
- The defcli! macro now has a special syntax for declaring flags, their
arguments and descriptions.
Addresses #1981, #1925, #1816, #1721, #1322
Straight throws an 'emacs-version-changed' error if you load it with a
version of Emacs it wasn't compiled with. This update causes this to
emit a more helpful error.
- Eager-load all core autoloaded libraries if autoloads file isn't
present.
- Renames functions to be more descriptive of their true purpose:
- doom-initialize-autoloads -> doom-load-autoloads-file
- doom-load-env-vars -> doom-load-envvars-file
- Use doom-module-p instead of featurep! for backend use (the latter is
mainly syntax sugar for module use, and evaluates at compile/expansion
time, which may cause hash-table-p errors early in the startup
process).
- Reorder plist library to prevent load order race condition with the
functions using the macros that haven't been defined yet.
There are a few kinks to iron out, but for the most part it's done. Doom
Emacs, powered by straight. Goodbye gnutls and elpa/quelpa issues.
This update doesn't come with rollback or lockfile support yet, but I
will eventually include one with Doom, and packages will be (by default,
anyway) updated in sync with Doom.
Relevant threads: #1577#1566#1473
IMPORTANT: This is a breaking update for Mac users, as your shell
environment will no longer be inherited correctly (with the removal of
exec-path-from-shell). The quick fix is: 'bin/doom env refresh'. Also,
the set-env! autodef now does nothing (and is deprecated), be sure to
remove calls to it in your config.
Smaller changes:
+ This update also adds --no-* switches to doom quickstart
+ Includes general improvements to the documentation of several bin/doom
commands.
+ Moves doom/reload* commands to core/autoload/config.el
+ doom/reload-project has been removed (it didn't actually do anything)
The breaking change:
This update adds an "envvar file" to Doom Emacs. This file is generated
by `doom env refresh`, populated with variables scraped from your shell
environment (from both non-interactive and interactive sessions). This
file is then (inexpensively) loaded at startup, if it exists.
+ The file is manually generated with `doom env refresh`.
+ It can be regenerated automatically whenever `doom refresh` is run by
running `doom env enable` (`doom env clear` will reverse this and
delete the env file).
+ `doom quickstart` will ask if you want to auto-generate this envvar
file. You won't need it if you're confident Emacs will always be
started from the correct environment, however.
+ Your env file can be reloaded from a running Emacs session with `M-x
doom/reload-env`. Note: this won't work if the Emacs session you're
running it in doesn't have a correct SHELL set. i.e. don't use this to
create your first env file!
The idea isn't mine -- it's borrowed from Spacemacs -- and was
introduced to me in #1053 by @yurimx. I was impressed with it. Prior to
this, I was unhappy with exec-path-from-shell (no hate to the dev, I
understand its necessity), and 'doom patch-macos' wasn't ideal for mac
users (needed to be reapplied every time you update Emacs). What's more,
many users (even Linux users) had to install exec-path-from-shell
anyway.
This solution suffers from none of their shortcomings. More reliable
than patch-macos, more performant and complete than
exec-path-from-shell, and easily handled by bin/doom.
Done to make bin/doom produce better debugger output (and more readily).
A lot of bin/doom errors aren't recurring, so it's better to produce the
full error report ASAP.
