See 6f1c0f7cc7 for part 1.
Turns out startup.elc likely exists on most Emacs installations (and,
since it's so integral to Emacs, it likely gets special treatment), so
it was a poor heuristic for this fix. Instead, a more variable target
would be calc-loaddefs.el.
On some systems, only calc-loaddefs.el.gz exists (in which case, we
should turn off the optimization). On others, calc-loaddefs.el
exists (so I'll assume it's safe to leave them on). I won't check for
calc-loaddefs.elc because it doesn't matter; calc.el explicitly
calls (load "calc-loaddefs.el") so it is never loaded.
Of course, you can sidestep the entire issue by building Emacs with
--without-compress-install, but it's not practical for users to
know/want to do that.
Amend: 6f1c0f7cc7
Some installs of Emacs do not come with byte-compiled versions of its
bundled elisp files, so when loading them, Emacs falls back to loading
its *.el.gz files. This would be fine if it were not for a startup
optimization Doom employs, where it sets file-name-handler-alist to
nil (and by doing so, robs Emacs of the ability to read compressed
elisp). This causes "symbol's value as variable is void: \213" errors at
startup.
With this commit, Doom now disables this optimization early if it
suspects this applies to your install. But time will tell if it's early
enough.
Ref: https://mail.gnu.org/archive/html/emacs-devel/2022-08/msg00234.html
BREAKING CHANGE: Before, 'doom ci' would load
$GIT_WORKING_TREE/.github/ci.el, to give users/projects an opportunity
to provide project-local configuration for bin/doom (mainly for CI/CD).
Now, this ci.el file is no longer loaded and instead, *all* bin/doom
sessions will walk up the file tree and load the first .doomrc it finds.
This gives bin/doom users a more general place configure all of its
commands, and not just 'doom ci' commands.
Extras:
- Adds .doomrc to auto-mode-alist (so that it starts in
emacs-lisp-mode).
- Adds -o/--file option,
- If -o/--file is passed a dash, print codeowners to stdout,
- Adds --dryrun option,
- Will accept literal string entries in doom-make-codeowners as
standalone lines (useful for comments).
doom-enlist is now a deprecated alias for ensure-list, which is built
into Emacs 28.1+ and is its drop-in replacement. We've already
backported it for 27.x users in doom-lib (in 4bf4978).
Ref: 4bf49785fd
In the future, should doom-core-dir or {doom-core-dir}/packages.el
change, 'doom upgrade' won't leave the repo in a broken state.
Unfortunately, this cannot retroactively prevent the issue; users will
experience this as soon as they update to b9933e6 or beyond, so users
will have to upgrade manually to overcome it:
cd ~/.emacs.d
git reset --hard 35a89bdfa6
git pull origin master
doom sync -u
Fix: #6598
Amend: b9933e6637
BREAKING CHANGE: This restructures the project in preparation for Doom
to be split into two repos. Users that have reconfigured Doom's CLI
stand a good chance of seeing breakage, especially if they've referred
to any core-* feature, e.g.
(after! core-cli-ci ...)
To fix it, simply s/core-/doom-/, i.e.
(after! doom-cli-ci ...)
What this commit specifically changes is:
- Renames all core features from core-* to doom-*
- Moves core/core-* -> lisp/doom-*
- Moves core/autoloads/* -> lisp/lib/*
- Moves core/templates -> templates/
Ref: #4273
