jwiegley/use-package@a6e856418d -> emacs-straight/use-package@fc8449bb59
- use-package was removed from MELPA (melpa/melpa@f008216) and
jwiegley/use-package is no longer "maintained" (i.e. it's now bundled
with Emacs). Straight now defaults to fetching it from
emacs-straight/use-package, where no commit by a6e856418d2e exists, so
I bump it to one that does (as the emacs-straight is the most
up-to-date mirror).
Ref: melpa/melpa@f008216272
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
In order to make imenu in elisp buffers more useful:
- Sections are given the highest precedence, and should only show lines
with more than two semicolons at the start of the line.
- Fixes an issue where cl-defstruct blocks with options in its NAME
argument were missed by imenu. I.e. with (cl-defstruct (foo ...)),
`foo` would not show up in imenu.
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
Recent changes to early-init.el accidentally moved some arguments
intended for `load` to an inner `let`, which means only the last
argument gets passed to `load`. This results in
```
> Debugger entered--Lisp error: (wrong-type-argument stringp nosuffix)
> load(nosuffix)
> (or (load (let ((windows? (memq system-type '(ms-dos windows-nt cygwin)))) (expand-file-name...
```
when starting Doom (or running a doomscript) with DOOMPROFILE set.
Move these arguments back out of the `let`.
Amend: 9ae7aa1122
