I do not see any evidence of a [tab] binding in `outline-mode-cycle-map`
in Emacs29, Emacs30, nor Emacs31. Moreover, this keybinding is
overriding our TAB keybinding in GUI Emacs, so YaSnippets are not being
expanded.
company-lean was removed from MELPA. Since lean4 support is around the
corner and Doom has deprecated its support for Company, I'll simply
remove this package.
Ref: melpa/melpa@11196af312Fix: #8159
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
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
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.
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.
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.
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.
With +extra enabled, this module would activate `prettify-symbols-mode`
in any buffer where `prettify-symbols-alist` is non-nil, whether or not
`+ligatures-extra-alist` has an entry for the current major mode (or a
parent thereof). This behavior is poor UX, since the user may be
expecting that a empty entry for some `X-mode` in
`+ligatures-extra-alist` should mean *no` prettify-symbols-mode` at all
in `X-mode`.
With this, `+ligatures-extra-alist` is now the authority. An empty entry
for `X-mode` will result in `prettify-symbols-mode` *not* being
activated there. If that entry *isn't* empty, it will be combined only
with the global default value of `prettify-symbols-alist`, not any
pre-existing buffer-local value, to make the end result deterministic,
because some modes have their own defaults for it (like
`lisp-prettify-symbols-alist`, `js--prettify-symbols-alist`, and
`rust-prettify-symbols-alist`).
Fix: #7440
Forgot that `ob-dot.el` exists in Org. I blindly expected the
`graphviz-dot-mode` package to provide babel support in f6b7e8a.
Also, `org-src-lang-modes` expects its CDRs to omit the -mode suffix,
which should fix syntax highlighting of graphviz/dot babel blocks.
Amend: f6b7e8ae48
Ref: #7546
`racket-mode` recently added `racket-hash-lang-mode` as an alternative
major mode.
Close: #7543
Co-authored-by: hlissner <hlissner@users.noreply.github.com>
