Leave it to modeline modules, plugins, and/or the user to support this
plugin, rather than impose winum's (rather destructive) side-effects on
them all.
This regression was introduced in 5a5195b; it broke `package!`s ability
to override the recipes of packages declared by other modules, due to
some API assumptions that aren't true yet (in unpushed post 3.1 work).
Amend: 5a5195b84dFix: #6901
The add-node-modules-path package calls `npm bin` to locate the
node_modules/.bin, and does so while invoking the user's $SHELL, which
can be very expensive depending on the user's shell configuration,
possibly adding seconds to the startup time of any JS/TS file.
To mitigate this, I replace the package with a much faster, and in-house
heuristic. Folks with more complex needs should be using direnv anyway.
Fix: #6878
Sync definition of __DOOMGEOM in bin/doomscript with corresponding
variable of bin/doom.
* bin/doomscript (__DOOMGEOM): split tput call into two separate calls
Ref: beef0aef02
The current config is kinda confusing, it uses the same symbol for both
forwarded/passed mails and replied mails. FontAwesome provides a nice
icon for "reply", why not use it!
For some reason, the transient-append-suffix adding magit-worktree back
to magit-dispatch — after its potential replacement by
magit-gitflow-popup — was having no effect. (It does when moved into
(after! magit-gitflow), so the issue must have something to do with when
transient-append-suffix is called.) magit-worktree wasn't appearing in
the magit-dispatch popup when magit-gitflow was enabled, nor was the '*'
keybind for magit-worktree in effect outside (or inside) the popup,
unlike '%' for magit-gitflow-popup.
Replace the ineffectual transient-append-suffix with a normal and visual
mode keybind for magit-worktree in magit-mode-map (and move the
unconditionally defined keybind for magit-gitflow-popup into (after!
magit-gitflow)). Also, append the magit-gitflow-popup transient suffix
to magit-worktree instead of replacing it, so that the latter still
appears in magit-dispatch (though under the original keybind 'Z' — which
isn't really an issue, since evil-collection-magit doesn't seem to
update the keybinds of any of the other commands accessible from
magit-dispatch — but also callable with '*').
warning-suppress-types' pre-29 documentation suggests that it accepts a
list of symbols, but a recent, upstream correction changes this.
Ref: emacs-mirror/emacs@d5ee49c25c
Amend: 8c442d84b9
C-S-s while company is completing shoudl bring up the results in your
completion framework of choice (ivy, helm, vertico, etc), but failed to
do so for vertico (for any completion backend besides company-capf
perhaps).
BREAKING CHANGE: Removes the eval-when-compile! macro. I recently
discovered cl-eval-when and it serves this macro's purpose well
enough (and is autoloaded+built-in).
This macro wasn't used anywhere in (published) Doom code, however, and
users shouldn't really be using it, so its removal is unlikely to cause
any actual breakage.
a4b5831 removed this let-binding because I expected the function to
capture it, which seems to be the case in general, except for #6865.
Since add-transient-hook! could conceivably be used in an elisp file
with lexical-binding off, I'll take fewer chances and live with a little
redundancy.
Amend: a4b58311daFix: #6865
`startup--load-user-init-file` persists its original
user-emacs-directory in a lexical binding that we cannot affect from
early-init.el, and uses it to find init.el. This prevents non-Doom
profiles' init.el files from being loaded.
A way around this is to have our own $EMACSDIR/init.el that loads
{user-emacs-directory}/init.el, but that's unnecessary work and ruins
our users' ability to use their $EMACSDIR as their $DOOMDIR, so I opted
for advice instead, to force it to recognize the changed
user-emacs-directory.
Fix: https://discourse.doomemacs.org/t/3251
To quote `user-emacs-directory`'s docstring:
> Note that this should end with a directory separator.
However, users may forget to add one in their profile configs, which
will cause errors.
Fix: #6608
Some time ago I noticed the cooperative lock file management wasn't
working as I remember. I forget what exactly I was thinking, but
basically I've poked at the code until it seems to work better.
It's possible for these hooks to be triggered recursively, such as in
the case of emojify's "Emoji images not available should I download them
now?" prompt (reported upstream).
Fix: iqbalansari/emacs-emojify#100
Fix the handling of a nil path within doom/delete-this-file.
If path is nil (e.g. called interactively when buffer is not visiting a
file), avoid calling abbreviate-file-name on nil, otherwise an error
will be signaled:
(wrong-type-argument stringp nil)
Additionally, fix the subsequent path checks. These were treating two
distinct scenarios as a "Buffer is not visiting any file" user-error:
- nil path
- non-existent path
- Only the first should result in that error. The second should proceed
to the next path check (which was previously unreachable), to signal
the appropriate error, "File doesn't exist: %s".
In 4d9ea6853b I reacted to a either a change that I presume occurred
in org-msg at some point, or behaviour originally unnoticed, that led to
bulk-selected files being attached in reverse. Further investigation has
indicated that this isn't actually making attachment order work as
expected, just hiding the reverse behaviour from bulk-attachment. The
better approach is to keep the dired mark reversal, and change
org-msg-attach-attach to add new files to the end, not the start, of the
list of attachments.
There are two changes to the default optional read-file-name arguments
that should be made for the purpose of attaching files:
1. The optional MUSTMATCH argument should be set, as one can't exactly
attach non-existent files.
2. The INITIAL argument should be set to the empty string so that if
default-directory is customised for some reason or another that
selecting it leads to the expected directory being selected.
Without INITIAL or DEFAULT-FILENAME being specified, the current file
path will be used, which is never desirable as this is simply a path
to the message buffer.
Replace the rather crude "don't do anything if already in a mu4e-y
buffer" behaviour with a more refined approach that tries to find the
live mu4e buffer likely of the most interest and switch to that, before
calling (mu4e) if no such buffer is found.
A mistake in 5a5195b caused modules without an explicit :depth to be
loaded in the wrong order (because their final depth wasn't cached
correctly, and so were all given a depth of 0, thus falling back on
their insertion order, which is precisely what 5a5195b was trying to
fix). This commit fixes that and changes the module cache vectors to
match the structure of doom-module-context, for consistency.
Amend: 5a5195b84dFix: #6813Fix: #6859
This macro used to be `doom-with-context`, but was renamed in the middle
of backporting f9201eb218, but these references were missed.
Fix: #6849
Amend: f9201eb218
The doctor would look for stale byte-code in *all* build directories,
which was excessive and produced many false positives for folks who use
multiple versions of Emacs or have recently up/downgraded.
doom-module-from-path fails to deduce the module from some paths (it
seems to struggle with doom-user-dir in some cases), causing a (aref nil
2) error (see #6845).
Fix: #6845
Occurs during non-interactive startup of the user's config (e.g. 'doom
doctor'), while :ui (modeline +light) is enabled.
This is a makeshift solution until I get around to finishing the +light
feature.
Doom is slowly transitioning away from requiring that its doom-*-dir
variables end in a slash (see two refs below), but there are some
vestiges of it left. This is one of them.
Fix: #6842
Ref: 00e8f6b72a
Ref: b914830403
The `if` clauses were swapped, such that a non-symlinked path was shown
like,
~/.config/emacs/ -> ~/.config/emacs/
and a symlinked path was shown as,
~/.config/emacs/
