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
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.
