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
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
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.
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`.
Fixes the broken Agda auto mode in Doom Emacs caused by the
introduction of mimer in Agda 2.7.0.
* modules/lang/agda/config.el (agda-auto-mode):
replaced agsy with mimer for auto mode call.
BREAKING CHANGE: This backports some architectural choices from v3.0.
This changes Doom's module API, renaming some functions and removing
others, in order to facilitate some new features, prepare to move Doom's
modules into separate repos, and make way for two, much larger breaking
commits coming in the next few days.
This commit won't break anything for users unless they're tinkering with
Doom's internals/using its `doom-module-*` API directly. I am avoiding
broader backwards incompatibilities until the 3.0 release.
What's new:
- Negated flags. (modulep! :editor evil -everywhere) will return non-nil
if :editor evil is active without its +everywhere flag.
- `modulep!` now takes multiple flags to simplify AND checks. E.g.
(and (modulep! +foo)
(modulep! +bar)
(not (modulep! +baz)))
Can now be expressed with:
(modulep! +foo +bar -baz)
- Adds pcase matchers for `doom-module-context` and `doom-module`
structs, making the following destructuring binds possible:
(pcase-dolist ((doom-module group name flags features)
(hash-table-values doom-modules))
...)
This will be used more in v3.0.
- Adds file cookie support to module init.el and config.el files.
Here's a summary of breaking changes made in this commit:
- `doom-module-context` was changed from a vector to a struct (record).
- `doom-modules` is now a table of `doom-module` structs, rather than
free-form plists.
- The following macros have been renamed:
- `doom-context-with` -> `with-doom-context`
- `doom-module-context-with` -> `with-doom-module`
- The followings functions have been replaced/removed:
- `doom-module-context`+`doom-module-context-get` -> `doom-module`
- `doom-module-set` -> `doom-module--put`
- `doom-module-p` -> `doom-module-active-p`
- `doom-module-context-key` (is now a getter with the same name)
- `doom-module-put` (removed)
- `doom-module--context-field` (removed)
- The signatures for these functions have changed:
- `doom-module-get CATEGORY &optional MODULE PROP` ->
`doom-module-get (GROUP . MODULE) &optional PROP`
- `doom-module-locate-path CATEGORY &optional MODULE FILE` ->
`doom-module-locate-path (GROUP . MODULE) &optional FILE`
- `doom-module-expand-path CATEGORY MODULE &optional FILE` ->
`doom-module-expand-path (GROUP . MODULE) &optional FILE`
- Adds the following functions
- `doom-module-exists-p`
- `doom-module-key`
- `doom-module->context`
- `doom-module<-context`
- Removes the following variables
- `doom-module--empty-context`
This commit results in a little redundancy, which I will address in
parts 2/3 and/or v3.0.
factor/fuel@31dc1a386b -> factor/fuel@6d0e98494f
Melpa's upstream and recipe for `fuel` changed (see
4a3d7cdefa):
previously it was pulled from a subdirectory of the main `factor`
repository, it now has its own repository. Applying Doom's previous pin
to the new recipe does not seem to work correctly, so update.
Toggle behavior:
The `(integerp current-prefix-arg)` check didn't appropriately catch
`C-u`/`SPC u` prefixes. This attempts to use `(prefix-numeric-value
current-prefix-arg)` instead to normalize these cases.
Variable naming:
I'm not sure if this was supposed to continue to be called
`+mu4e-compose-org-msg-toggle-next` or if the rename to private
`+mu4e--compose-org-msg-toggle-next` was intentional and the usage
wasn't updated accordingly. I see the `mu4e` README still mentions it,
so I would guess the former and this was a typo.
Ref: #8073
Amend: a78237cc01
These two commands were renamed upstream and pulled in in 1fa1eba:
- python-pytest-function-dwim -> python-pytest-run-def-or-class-at-point
- python-pytest-function-dwim -> python-pytest-run-def-or-class-at-point-dwim
Amend: 1fa1eba5ac
Ref: wbolster/emacs-python-pytest#75
These optional dotfiles indicate the root of a module or module
group (:lang), and will later contain module metadata. They will also
serve as an alternative to packages.el and doctor.el, and will aide the
parts of the v3.0 module API concerned with resolving the current module
from a path (`doom-module-from-path`), which currently rely too heavily
on parsing path strings.
For now, however, they're simply placeholders.
In the absence of a .clang-format file, imposing the value of
`c-basic-offset` onto clang-format seems like reasonable, default
behavior. Like all other cases, this can be disabled by unsetting
`apheleia-formatters-respect-indent-level` globally or mode-locally with
`setq-hook!` or similar.
As per the description in 6671adc68, this module should always use
Helpful's functions as long as Helpful is available (ie. not explicitly
disabled by the user in packages.el). The remapping of `describe-symbol`
is irrelevant here - the user might prefer to rebind `C-h C-o` to
`describe-symbol` (as `helpful-symbol` cannot look up types), but that
doesn't necessarily mean they want this module not to use it.
Otherwise, `prettify-symbols-alist` will be set to a list whose first
element is the mode name, a symbol. That makes `prettify-symbols-alist`
an invalid alist, so when `prettify-symbols-mode` is enabled, there's a
type error in `prettify-symbols--make-keywords`.
Amend: c07f359d64
