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
BREAKING CHANGE: This deprecates the IS-(MAC|WINDOWS|LINUX|BSD) family
of global constants in favor of a native `featurep` check:
IS-MAC -> (featurep :system 'macos)
IS-WINDOWS -> (featurep :system 'windows)
IS-LINUX -> (featurep :system 'linux)
IS-BSD -> (featurep :system 'bsd)
The constants will stick around until the v3 release so folks can still
use it -- and there are still some modules that use it, but I'll phase
those uses out gradually.
Fix: #7479
doom-file-write's :mode parameter now accepts a cons cell, whose CDR
will determine the file mode for directories that get implicitly created
by the function.
The old check was a bug fix to work around noisy values that somehow
made it into diff checks. The `package!` symbol is never actually
present in the list of values yielded by the search in `read-package`,
so this commit alters the lookup to respect what is actually present,
thus guaranteeing that `destructuring-bind` succeeds and bump diffs are
actually detected.
BREAKING CHANGE: This commit replaces all-the-icons with nerd-fonts. Any
all-the-icons-* function calls or variable references in your private
config will break and should be replaced with their nerd-icons-*
equivalent. That said, Doom will continue to install all-the-icons for
a while, so feel free to load it if you don't want to fully commit to
the change yet.
This change is happening because nerd-icon has wider support for GUI and
TUI Emacs; has a larger, more consistent selection of symbols; plus unicode
coverage.
Fix: #7368Close: #6675Close: #7364
