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/
* lisp/cli/help.el (doom help): move to lisp/cli/meta.el, and add :dump
definition.
* lisp/doom-cli.el:
- (doom-before-init-hook): trigger hook after the file is done
loading.
- (doom-cli-backtrace-depth, doom-cli-straight-error-lines,
doom-cli-benchmark-threshold): rename these variables' prefix from
`doom-cli-` to `doom-cli-log-`.
- (doom-cli--plist): rename to doom-cli--group-plist, to better clue
in what changes it.
- (doom-cli-context-parse): remove unused letbind (argsleft).
- (doom-cli-create-context-functions, doom-cli-before-run-functions,
doom-cli-after-run-functions): define with defcustom instead of
defvar, to indicate that they are (especially) intended for end-user
configuration.
$EMACSLOADPATH is read to pre-fill load-path. Empty entries therein are
substituted with the default value of load-path. I am mirroring this
behavior with the $DOOMPATH variable.
If lisp/doom.el does not exist, then we assume the user isn't loading a
Doom config and fall through to $EMACSDIR/early-init.el, if it exists.
However, `load`'s NOERROR argument suppresses more than just
file-missing errors -- it suppress permissions errors and other
legitimate IO errors that I want to treat as error states, not
fall-through states. This commit fixes that.
* early-init.el (gc-cons-threshold): Set a reasonable more default for
gc-cons-threshold for non-Doom configs (16mb), instead of
most-positive-fixnum, which would eventually cause
freezing/stuttering for non-Doom profiles.
A regression introduced in 4efaf68, cause by an incomplete refactoring
of the loop, where not all instances of `key` were changed into `group`
and `name`.
Amend: 4efaf6837bFix: #6840
This is a regression introduced in 1c4217a.
Doom unsets command-line-x-option-alist when it reasonably suspects it's
not running in an X environment. The heuristic for that is checking when
`initial-window-system` is set to `x`, but as it turns out, PGTK builds
of Emacs set this to `pgtk`, so PGTK users were deprived of Emacs' X
switches, like --geometry, --foreground, --font, etc (they'd throw an
"Unknown option" error at startup). This was fixed.
However, this heuristic isn't perfect. Not all PGTK users are on X (I'd
hazard to guess most of them aren't). So a more reliable check is
needed (and it's too early in the startup process for us to call
display-graphic-p on any frame). The `(not IS-LINUX)` or `(or IS-MAC
IS-WINDOWS)` I had previously used (before 1c4217a) wasn't enough
either, because users can (and do) install X on these
systems (especially where WSL is involved). Still, until I've found a
better one, this is an acceptable workaround.
Amend: 1c4217aa27
It's kind of a pain to have different behavior when you're debugging.
Some errors may not present without them, so best to remain predictable
and permit these optimizations even when debug mode is on.
