cli/gc.el accidentally snuck into 5e84709, along with a particular
v3-isms that doesn't belong in Doom yet, such as autoloads in CLI libs
and them providing subfeatures of doom-cli, rather than doom-cli-*.
These have been reversed for now.
Amend: 5e84709577
`letenv!` is a layover from the days before
`with-environment-variables` (introduced in 28.x), and it remained
afterwards because I preferred the shorter name. From v3 and onward,
Doom's core will be put on a diet which, among other things, will
include culling redundant or superfluous functions/macros like this one.
Many users seem to treat `doom/reload` like a 1-to-1 replacement for
`doom sync` + restart Emacs (which it is not), and are surprised when it
fails to properly "reload" their config. I'm considering removing
`doom/reload` altogether for this reason, or turning it into a light
wrapper around `restart-emacs`, but for now I'll settle for recommending
it less in documentation and comments. The references in docs/*.org will
be dealt with later.
The performance benefit of doing so has always been questionable or, at
best, negligible, but has caused numerous issues over the years. The
latest one being #8162, where byte-compiling a profile init file with
too many package autoloads would consume more than 255 opcodes, causing
an overflow error.
For simplicity's sake, Doom will no longer byte-compile this file.
Fix: #8162
Freeing this up to use for a future command (doom init), and because
'doom install' ought to be used very rarely and deliberately, so it
shouldn't have a convenient alias anyway.
These commands were removed in an ongoing effort to slim down Doom and
its core. The `doom/goto-private-*-file` family of commands were
redundant with `doom/open-private-config` and
`doom/find-file-in-private-config`.
This is an old issue that's haunted Doom for a while. I had initially
planned to wait until the switch to Elpaca, but I decided to just sit
down and solve this.
This ensures package autoloads are always written in depth-first
dependency order to Doom's profile init file, preventing load-order
issues like the notorious void-function geiser-activate-implementation
error. `geiser` needs to be built before any `geiser-*` plugins, since
its plugins reference variables/functions in geiser's own autoloads, but
there's no way to enforce package order in `straight--build-cache`
currently, and subsequent package updates (or just deleting package
directories by hand) can change the order of straight's build-cache in
subtle ways.
Fix: #7693Fix: #7472
The lexical bindings for the load suffix variables in early-init.el does
this work already, so affecting the global state of these variables is
redundant and overkill.
It seems either Emacs' warning library and/or debugger relies on
custom.el functionality at load time to properly function. If
`custom-dont-initialize` is non-nil when a warning or error occurs,
Emacs fails to fully load the `warning` or `backtrace` libraries,
causing this error to obscure the true warning/error with:
Error in delayed-warnings-hook (display-delayed-warnings): (void-variable
warning-minimum-log-level)
`doom-module-load-path` will be removed in the next big refactor commit,
so as a stop gap, I simply move it to doom.el to resolve the reference
error.
This also removes the obsolete alias `doom-modules-dirs`, since it's
been deprecated long enough (and `doom-module-load-path` itself won't be
around much longer anyway).
Ref: #8147
Amend: 8cafbe4408
The issue required a more systemic fix, because the former (before
9e6c46a even) only recorded `Info-directory-list` for the packages that
were installed/updated in that `doom sync` session, forgetting all
packages installed in the past.
Fix: #8143
Amend: 9e6c46a332
Autoloads were accidentally reversed in 114f996. For some packages,
autoload order is signifcant (such as json-mode, which autoloads
json-mode-auto-mode-list first, then modifies it in a later autoload).
Fix: #8143
Amend: 114f99688c
Some packages do funky things in their autoloads, so care is needed to
closely emulate an autoloading environment when loading them, however,
in 8cafbe4, Doom wraps these autoloads in a function, thus ensuring
they're executed without `load-file-name` or `load-in-progress` set,
which some packages will expect these in their autoloads.
This fixes the (wrong-type-argument stringp nil) error some folks see
with certain packages doing said funky things in their autoloads (like
realgun in the :tools debugger module).
Fix: #8143
Amend: 8cafbe4408
'doom upgrade' naively evaluates straight's recipe so it can delete
it (so 'doom sync' will upgrade it), but the
`straight-repository-branch` reference will error out for users updating
Doom from before 8cafbe4 to a commit after it, since its value now lives
in `doom-straight`, which may not be loaded yet.
Rather than further embed this hack (and because I don't want to spend
more time on straight.el accommodations than I have to, since it'll be
replaced with Elpaca soon), I simply replace the reference with its
value.
Fix: #8140
Amend: 8cafbe4408
Seems these two macros were marked obsolete very recently on Emacs 31.1
in favor of (if|when)-let*. Since the change seems premature (judging
from the mailing list discussion), and because I disagree with the
change (and will redefine (if|when)-let if they actually go through with
removing them), I simply silence the warnings altogether. They're not
helpful for the end user and end up only spamming them with unactionable
warnings.
I'll wait until upstream figures it out before I make any decisions.
Ref: https://lists.gnu.org/archive/html/emacs-devel/2024-10/msg00637.html
BREAKING CHANGE: This restructures Doom's core in an effort to slim it
down and partially mirror architectural changes coming in v3. This is
part 2 of 3 commits (part 1 being 1590434), done to facilitate a change
in part 3 that will introduce a new `doom!` syntax for pulling
third-party module libraries from remote sources (similar to `package!`
statements). I am backporting this from V3 so I can move our modules out
into separate repos sooner than later, so development on modules can
continue separately without interfering with v3's roll out.
Though this is labeled a breaking change, it shouldn't affect most users
except those few tinkering directly with Doom's internals.
Ref: 15904349cf
This prevents edge cases where these directories are created with
permissions that prevent Emacs from writing to them. This can happy
either due to an overly-restrictive default umask,
`set-default-file-modes` call, or if `doom-profiles-save` is instructed
to write a file whose parent doesn't exist yet.
Fix: #8134
