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
point-min and point-max were used in some places in
+fold--open-rec-between instead of beg and end. This caused
+fold/open-rec to open all folds rather than only the one the curser is
on.
consult-man is not a good drop-in replacement for man. consult-man
searches man pages and descriptions (like the apropos program).
The original man function lets the user pick a man page from the list of
man pages.
This is due to :align-to factoring in the margins into its alignment,
which is ever changing in the dashboard buffer (or anywhere
visual-fill-column is active).
Even though `mode-line-right-align-edge` was introduced in Emacs 30,
doom-modeline backports so, so its users should benefit from this as
well.
Close: #8114Fix: #7466Fix: seagle0128/doom-modeline#668Fix: seagle0128/doom-modeline#672
Co-authored-by: unipro <unipro@users.noreply.github.com>
Going forward, I'll leave it to each :lang module to document the LSP
clients they support/favor, and defer to lsp-mode/eglot's docs for their
support tables rather than maintain our own.
Close: #8131
The `-a` option will cause afew to process all the user's mail. If the
user has a lot of mail, this will take an extremely long time, every
time. The expected usage is to process only mail that has been tagged
'new' by notmuch (which requires the [correct
setup](https://github.com/afewmail/afew/blob/master/docs/quickstart.rst)).
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
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
