Users shouldn't be using both, and `load-theme` should be higher
priority (because it's easier to do by accident).
Fix: #8257
Amend: #8119
Amend: 50b9afbb2d
Like Fish, using nushell as your shell-file-name can cause downstream
issues wherever Emacs (or Emacs packages) spawn child processes via a
shell command and rely on its output. For example: diff-hl users may not
see a git gutter if nushell (or fish) is their $SHELL.
The broad /*rc rule, which is intended as a fallback, should be added to
the end of auto-mode-alist, not the beginning. Otherwise, for example,
it overrides the rule for .zshrc files.
Amend: cc18218889
Since 87a024e, the profile init files are no longer byte-compiled, so
this block of code -- responsible for deleting byte-compiled init files
-- is no longer needed.
Amend: 87a024ee90
The doom-*.el files will soon be moved to separate core modules (whose
load order the user can dictate); when this happens, this block could be
re-evaluated anytime the user calls `doom/reload` or otherwise reloads
the active profile.
Instead of advising load-theme, which was more opinionated, and broke in
instances where users (relying on `custom-enabled-themes`s setter) or
packages (like auto-dark) were enabling themes with `enable-theme`
instead of `load-theme`.
This also adds support for enabling multiple themes with `doom-theme`.
Fix: #8119
Cast too wide a net; there are likely too many *rc files that shouldn't
be treated as shell scripts.
Besides, there's already a fallback *rc rule for conf-mode in
lisp/doom-editor.el.
Revert: bdc35faff2
Assuming GPG is present and set up by default can be surprising for
beginners, so this commit makes GPG integration opt-in, behind a new
+gnupg flag in the :config default module. There'll be more added to
this later.
Regardless of DEEP?, a record's fields should be copied one level deep
at least, to ensure shallow changes to shallow copies don't affect the
original.
Amend: 169540ad3b
Emacs requires '-*- lexical-binding: t -*-' to be prefixed with an elisp
line comment (two semicolons), but due to our shebang shenanigans (which
are, unfortunately, necessary) starting this line with a :;, Emacs
ignores the `lexical-binding: t` at the top, thereby executing bin/doom
without lexical binding.
Until a better workaround is found, our CLI framework will have to
adapt. Fortunately, this only affects bin/doom and not any arbitrary
doomscript.
Error occurs on Emacs 30.0.92 or newer, because this variable (what it's
aliased to, at least) was moved to comp-run.el, upstream.
Ref: emacsmirror/emacs@e6a955d242
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.
