Some psuedo module categories (like :core and :user) don't have a module
component. Rather than display them as ':core nil' or ':user nil' in
module listings (like doom/help-modules), omit the nil entirely.
Some shells (like ksh on SDF) may complain about $((...)) arithmetic
expansion syntax. Rather than wrestle with old shells, I'll offload this
trivial operation to elisp instead.
Close: #6970
From now on, our documentation will assume your Emacs config lives in
~/.config/emacs, by default, rather than ~/.emacs.d. Support for the
latter is not going away, it will simply be mentioned less in the
literature, as all supported versions of Emacs going forward (and future
versions of Doom) will support (and prefer) XDG conventions.
The user manual will be updated separately.
Close: #6965
Co-authored-by: gagbo <gagbo@users.noreply.github.com>
Slipped by manual testing due to consult not being loaded at the time
and doom--help-search going to default grep-find usage instead of
hitting the failiure.
Amend: 54c4340740
`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".
