`doom doctor` throws a type error for enabled modules without a
doctor.el and/or packages.el file. This occurs because, in
in775ee2f04aad, `doom-module-expand-path` was changed to return nil if
the target file did not exist, and the doctor wasn't updated to handle
this. It passes `nil` to `load`, causing this type error.
Amend: 775ee2f04a
file-name-directory consults this variable for alternative strategies,
which is unnecessary work. (file!) won't (and should never be used in
any context where it could) return anything but a simple file path.
This command would skip over consecutive package! statements in the
generated commit message. This commit fixes that.
That said, this command is still a temporary measure until formal bump
CI/CD is done, but should make dealing with doom/bumpify-diffs and
doom/commit-bumps a little less painful.
When calling backward-kill-word (which is in turn is calling kill-new),
not only kill-ring variable should be overridden, but also
kill-ring-yank-pointer.
Otherwise when deleting a word backwards, kill-ring pointer is moved and
next yank will insert (not so expected) rubbish.
emacs-compat/compat@01fdf316a4 -> emacs-compat/compat@38280a7b54
- Switching to emacs-compat/compat so we can more closely follow the
source. The emacs-straight mirror can sometimes lag too far behind to
promptly address major issues.
- This, combined with 67b3d5a, should address odd byte-code issues to do
with compat (usually to do with magit).
Ref: 67b3d5a20486
This package is cropping up in packages everywhere. Managing it has been
a source of issues, so I'm making it a core package until v3, where
we'll be able to pin packages without explicitly installing them.
Library packages (like compat and transient) offer macros. Therefore,
any package that uses them (dependents) needs to be recompiled when
these are updated, but straight currently doesn't do this. As a
temporary workaround, this commit forces dependents to be rebuilt after
updates.
This is a bit too brute-force, but will do until v3, which will manage
dependency graphs and their complexities more efficiently.
In later versions of Emacs 29, this variable has been renamed without a
deprecation alias, causing void-variable errors wherever it is used.
Since it could potentially be used outside of Doom, I'll use a variable
alias until we formally drop 28 support (not for a long time).
Close: #7090
Co-authored-by: AdoPi <AdoPi@users.noreply.github.com>
In case straight prompts something like the following:
> In repository "git-modes", HEAD on "master" is behind default branch "main"
1) Abort
2) Checkout "main" (Choose this if unsure)
3) Magit log "master..main" and open recursive edit
This allows for more rapid 'doom sync'ing when testing different module
combinations, but puts the onus on the user to run `doom sync
--purge` (or `doom purge`, which will later be renamed `doom gc`) to
prune orphaned packages/repos.
Due to some packages and modules using this in some (non-GUI) builds of
Emacs. display-graphic-p isn't enough here, so rather than police all
the possible offenders, I've defined it to no-op in those cases,
instead.
Close: #6876
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
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
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
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
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".
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
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.
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
