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
`shell-command` erases the target buffer before piping output to it.
Which means the envvar file comment header was wiped out. This causes
trouble for the envvar file parser, which expects the envvar list to
start with two newlines.
- 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
I've replaced load-env-var with our own custom parser. load-env-var
expects a well-formatted env file, which neither env nor set produces,
which is what doom env uses to dump the shell environment.
This should fix issues that arise when envvars (like PATH) contain
arbitrary whitespace.
- Limits process-environment during scraping
- Add `doom-env-executable` and `doom-env-switches` variables
- Announce what commands were run to produce your env var within env var
file header
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.
