If the target directory wasn't in a project, this command would throw a
type error (see #8032).
This also adds more checks and informative error handling to the
command.
Fix: #8032
BREAKING CHANGE: This moves helpful.el out of core into :lang
emacs-lisp. Since most (all) people have this module enabled, this
shouldn't make a difference for most people, but if you're one of the
few that don't have :lang emacs-lisp enabled, Doom will revert to using
Emacs' built-in help.el and describe-* commands.
Others can also disable helpful with (package! helpful :disable t) if
they prefer Emacs' built-in help system, which wasn't possible before,
because it was a core package.
This was done as part of an ongoing effort to slim down Doom's core in
preparation for v3.
A user's shell config might destructively alter the shell's $PATH (also
common on MacOS, which destructively sets $PATH with its system dotfiles
for ZSH). This prevents the sub-shell spawned from `doom/reload` and
`doom/upgrade` from inheriting emacs' `$PATH`, which Doom adds
$EMACSDIR/bin to. Without this entry, these commands would fail to find
the Doom script.
Fix: #8027
Amend: a8ba8feecb
Before this, text that extended past the new line's length would
persist, causing garbled output like this:
> Ensuring packages are installed and built...
> Updating recipe repos...
> Cloning org-appear...r emacsmirror-mirror...
- No packages need attention
Which might lead you to believe org-appear is being cloned from
emacsmirror-mirror, but the full output is actually:
> Ensuring packages are installed and built...
> Updating recipe repos...
> Updating recipes for melpa...
> Updating recipes for nongnu-elpa...
> Updating recipes for gnu-elpa-mirror...
> Updating recipes for el-get...
> Updating recipes for emacsmirror-mirror...
> Cloning org-appear...
- No packages need attention
Wrap doom-customize-theme-hook and use that wrapper also when the local
doom--customize-themes-h-* hook is called immediately, otherwise
settings will be written to custom-file, which is what I've been trying
to avoid with all these takes!
Amend: 0b13525252
Ref: #7929Close: #7933
Co-authored-by: real-or-random <real-or-random@users.noreply.github.com>
Setting custom--inhibit-theme-enable to t isn't enough, since
custom--should-apply-setting will return non-nil if THEME is 'user.
Ref: #7929
Amend: 68771150ba
`custom-theme-set-faces!` calls `custom-theme-set-faces`, which will
mark the customizations for saving to custom.el. But
`custom-theme-set-faces!` is not intended for permanent customizations.
I fix this by setting `custom--inhibit-theme-enable` to prevent some of
the extra work `custom-theme-set-faces` does around changing faces, and
call face-spec-set manually.
Also renames doom--custome-theme-set-face to doom--normalize-face-space,
to better reflect what it does.
Close: #7929
Co-authored-by: real-or-random <real-or-random@users.noreply.github.com>
Toward our eventual goal of moving smartparens out of core, I've adapted
this from code provided by hpfr on Discord, which was adapted from
smartparen's syntax-ppss caching logic. `:config default` will need need
some attention before we can fully move smartparens to its own `:editor
smartparens` module.
Co-authored-by: hpfr <hpfr@users.noreply.github.com>
This one was sneaky. `doom-plist-merge` was mutating the second plist
fed to it, causing issues upwind of its uses. In #7925, for example,
calling `doom-package-recipe` to read a package's recipe would end up
altering it, copying sub-properties of :recipe to other packages'
recipes.
If you've hit #7925, you'll also need to delete your build-cache to get
around the error. I.e.
rm -f $EMACSDIR/.local/straight/build-*-cache.el
doom sync # or upgrade
Fix: #7925
If DIR is not a project and does not have root markers, create a
transient project instead. This ensures that `project-find-file-in`, and
by extension vertico, is still used in non-project directories instead
of falling back to `find-file`
Ref: 1b0af3bfc7
Calling (doom-adjust-font-size 1) repeatedly would keep increase the
font size because an increment is passed.
When loading themes, the doom-big-font-mode minor mode gets loaded again
therefore it causes the font to get increased.
Fix: #7845
BREAKING CHANGE: This removes the pcre2el package, which Doom was using
solely for one function to escape PCREs. In the interest of thinning out
Doom's core, I've hoisted a simpler version of the function into Doom's
stdlib so I can remove the dependency.
To make these errors more consistent with similar commands/operations,
as well as rely less on cl-check-type (cl-lib's understanding of the
`font` type is a bit odd; they'd emit warnings/errors about this, but
still perform the checks -- I opted to check more explicitly instead).
* lisp/lib/autoloads.el(doom-autoloads--scan) Remove invoke
`file-truename` of file, keeping symbolic from being converted to a real
path.
* lisp/doom-modules.el(doom-module-from-path) Replace
`file-in-directory-p` with `string-match` to determine the module to
which the file belongs.
Fix: #7821
Although this is a refactor for normal users of Doom, it is a bugfix for
one (I assume) unsupported configuration: when Doom is not running from
a git checkout. In that case, `doom--help-package-configs` currently
returns Git's error messages. This breaks `doom/help-packages` because
it expects each returned line to contain at least one `:` character, so
it errors out with `Wrong number of arguments: (file line _match &rest),
2`.
Using ripgrep here should be equivalent for normal users as long as they
have not added untracked files not covered by Doom's .gitignore.
After switching to the sudo-ed tramp buffer, this restores the point and
scroll position of the window to match the source buffer.
I exploit save-place here instead of simply saving/restoring (point)
and (window-start), because I believe it's better UX that save-place
treat the two buffers as effectively the same now and in the future, and
record the last cursor position equally between them, even if the
implementation is messier. This *could* be generalized into an advice
for save-place-find-file-hook and save-place-to-alist, but that's an
experiment for another day.
This is an experimental implementation and may change later.
Close: #7181
Co-authored-by: YourFin <YourFin@users.noreply.github.com>
auto-save can trigger processes that hang silently in the background,
making those buffers inoperable (hanging Emacs) for the rest of the
session, even if they are killed (tramp caches them), so I suppress them
solely for these temporary tramp buffers created by doom/sudo-find-file
and doom/sudo-this-file.
I backported `find-sibling-file` from Emacs 29+ in 198fe82, but it
passes a third argument (REGEXP) to `file-expand-wildcards` which wasn't
introduced until 29, so users on 28 or earlier would see a
wrong-number-of-arguments error (see #7795).
Rather than backport the entire `file-expand-wildcards`
function (risking other edge cases), I've advised its usage in
`find-sibling-file-search` to behave as it would in 29+ with a non-nil
REGEXP argument.
Amend: 198fe82b6dFix: #7795
If the buffer is an indirect clone, it may not have a buffer-file-name.
Also changes the command to throw an error if the current file has no
file path *and* is not a dired buffer.
Tools like these will be moved to a benchmark module later (or perhaps
to `:lang emacs-lisp`). For the time being, it only takes up extra space
that few users use.
I will slowly phase out projectile in favor of project.el, starting with
projectile-find-other-file, which -- as of Emacs 29 -- has a native
alternative: `find-sibling-file`.
Ref: doomemacs/community#1
It's possible for the user to type shell variables (something like
`$MYVAR/dir/filename`) as part of the filepath, so we need to call
`expand-file-name`.
When +vertico/find-file-in was replaced in 60e22fd with
+vertico/consult-fd-or-find, it changed a key behavior for
doom-project-find-file for Vertico users: instead of displaying an
initial list of all files under the target directory, it would display
nothing until the user entered in N * `consult-async-min-input`
characters, causing confusion (see linked comment).
Since Vertico integration modifies project-find-file-in's interface
appropriately, I leave it to that command instead.
Ref: https://github.com/doomemacs/doomemacs/issues/7312#issuecomment-1933404444
Amend: 60e22fd2eb
