- Is now much more fault tolerant (produces better errors)
- Now handles async.el process errors as well
- Standardizes data structure of thread responses
- Fix 'doom build' not byte-compiling stale dependencies of rebuilt
packages.
- Fix 'doom build' logging the wrong number of packages that were
rebuilt.
- Correctly replace references to load-file-name and $# in autoloads.
- Don't load resulting autoloads file twice
- Read package autoloads literally (a little faster)
This update addresses two evasive issues:
1. Packages updated with `doom update` would not rebuild correctly,
requiring a `doom refresh` afterwards,
2. Packages would fail to rebuild even if their byte-compiled files were
stale. The result: "*.el is newer than *.elc" warnings at startup.
`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.
Caused lecause straight is prompting for input in a headless
session *and* from a headless async child instance of Emacs. It waits
forever for input for a question we could never see or respond to.
How sad.
- Let-bind byte-compile-* vars instead of using file-local vars.
- Fix duplicate bullet point in "Copied backup..." message.
- Only display refresh message if cli command was successful.
Straight expects to be used interactively, which don't do (yet). Its
transactional system depends on idle timers, which don't run in a
noninteractive session, so we have to nudge it ourselves.
- Now handles errors from threads gracefully, rather than failing
silently.
- Exploits straights modification system to trigger rebuilds
later (instead of force-rebuilding after each update).
Before this update, the autoloads files were collected in
lexicographical order (by traversing straight's build directory). By
using straight--build-cache's keys (which are entered in the order they
were registered) we avoid issues like
- 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.
It would no-op if you responded "y" to the 'update them?' prompt, and
proceed if you responded "n".
Doom must be in its rebellious phase.
Also relevant: #1585
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
This has been deprecated for a while. I will remove it entirely with the 2.1
release, but for now, you can no longer patch your app bundle with this.
Use 'doom env refresh' instead.
- Move subr-x/cl-lib loading to core-lib
- Revise docstrings for and rename various CLI functions to be more
descriptive and up-to-date
- After regenerating autoloads file, bin/doom will try to reload
autoloads files remotely, through the server/daemon, if possible. This
is highly experimental and could break
Sets out to solve a number of issues with the package management
process. Namely:
- To-be-removed packages that are simply being removed are no longer
incorrectly labeled "quelpa->elpa", but "removed" instead.
- A backend (elpa vs quelpa) column was added to the package listing
confirmation when running `doom update`.
- Doom now correctly recognizes that packages installed with a psuedonym
are installed, and will not endlessly attempt to uninstall and
reinstall them on every `doom refresh`.
- Packages declared with :built-in will no longer lose their built-in
marking if said package is not actually present in Emacs' site load
paths. i.e. if you say it's built in, Doom won't question it.
- package!'s :ignore property is now treated as a form whose evaluated
result will be used as its value.
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.
If the user had no ~/.doom.d/init.el to begin with, and never reads it
after it's been created (by `doom quickstart`), then Doom can't possibly
know what modules to install packages for, therefore no packages get
installed!
The private module won't be byte-compiled implicitly anymore, as it can
cause unexpected problems with stale code and config portability.
doom compile -> only compiles ~/.emacs.d
doom compile :core -> ~/.emacs.d/core
doom compile :plugins -> ~/.emacs.d/.local/packages/elpa
doom compile :private -> ~/.doom.d
- 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.
