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
For example, proper-list-p errors from uses of `use-package`, occuring
in Doom source files (or elisp in $DOOMDIR). This happened because
Doom's bootstrap process changed in 8cafbe4 without adapting this
module's elisp checker.
Amend: 8cafbe4408
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
CVE-2024-53920 describes an arbitrary code execution vulnerability
during macro expansion, which occurs during byte-compilation or when
evaluating macro calls in uncompiled elisp files.
Flycheck and flymake use byte-compilation to lint elisp files, exposing
users to this vulnerability. This commit attempts to protect users from
this by disabling both in elisp files that aren't part of a
project (because, presumably, untrusted elisp won't live in a project).
What a "project" is depends on your projectile settings, but generally
means a file that lives in a version controlled directory and/or a
directory containing a recognizable project root marker (like a
packages.json or Cargo.toml file).
This heuristic won't catch cases of untrusted elisp living within
legitimate projects, or the case where the user's $HOME is a project and
*all* their elisp files live under it, but there are already too many
ways to shoot yourself in the foot with Emacs to begin with, and
disabling fly(check|make) altogether stands a higher chance of making
people blindly re-enable them to "work around" the fact it's not
"working as expected", bringing them back to square one.
Anyhow, long story short, don't open elisp files you don't trust in
Emacs, mkay?
Ref: CVE-2024-53920
The +eval/send-region-to-repl command was adding an extra newline when
sending regions to REPLs, causing double prompts to appear. This removes
the extra newline for cleaner REPL interaction across all language modes.
* modules/tools/eval/autoload/repl.el (+eval/send-region-to-repl):
remove concatenation of newline after region
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.
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.
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
