I backported `find-sibling-file` in 198fe82 and included with it some
rudimentary `find-sibling-rules` rules for C++ and others. The C++ rule
made *.h(h|pp) files the siblings of *.c(c|pp) files, but not vice
versa, so users couldn't jump back to the source file with
`find-sibling-file`; a second rule is necessary.
These may be combinable, considering `find-sibling-file` deletes the
current buffer's filename from the list of candidates...
Fix: #7795
Ref: 198fe82b6d
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
I revisit all our startup optimizations to see how they fair in Emacs
29.x and 30.x. Most of them still hold up. I've revised and updated most
of the accompanying comments to better explain them, given what I know
now compared to when I first wrote them.
Doom makes multiple attempts to re-clone repos if they failed the first
time, however, if a user provides a :local-repo and that location isn't
a git repo, Doom assumes this it is the result of a failed clone, and so
deletes it to "try" again (which will fail). This can result in lost
work.
This prevents this from happening to packages/repos outside of
$DOOMLOCALDIR (all packages under $DOOMLOCALDIR must be git repos).
Fix: #7785
Amend: 3643c4dadd
Amend: 1fa8d3a4b9
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.
Now that mu4e has its own notification feature since 1.10 (and as of
this commit version 1.12 is already out), we can just use that. Much
less code to maintain.
Closes: https://github.com/doomemacs/doomemacs/issues/6896
- Make `+fold/close-all` work for outline-minor-mode.
- Distinguish between `zo` and `zO` for outline-minor-mode alone, by
binding `zO` to a new function `+fold/open-rec`. `zO` will now trigger
`outline-show-subtree` in outline-minor-mode, while `zo` will only
trigger `outline-show-branches`, keeping the subheadings folded. This
matches the behavior in org-mode.
- Fix a bug in `+fold/open-all`, introduced in
7b9d00d661, that makes it only operate
on vimish-fold folds.
Note that outline-minor-mode is still not enabled by default anywhere.
These changes are only to prevent incorrect behavior for users who
decide to turn it on themselves.
directory-empty-p was introduced in 28.1, but Doom still supports 27.1,
so 27.x users would see this error when running any bin/doom command
that clones packages.
Fix: #7779
Amend: 1fa8d3a4b9
At 0.1, Corfu pops up too aggressively and too often, even for fast
typists. This is especially disruptive with slow backends that might
block Emacs. I think 0.18-0.24 is the goldilocks zone, so I'll start
with 0.18, and maybe increase it later.
It seems the temporary branch that 'doom upgrade' creates is sometimes
left over after a 'doom upgrade', preventing the next 'git fetch' from
completing.
Ref: #7771
Caused by a regression originally introduced in b6b755d, but incorrectly
fixed in 89c56a3. Don't code while sleep deprived, kids.
Amend: 89c56a3393
Amend: b6b755dea4
12a765c introduced suppression of package-rebuilding prompts on 'doom
upgrade', but inadvertently reversed the check. This fixes that (and
refactors the if/or tree into a `cond`).
Amend: 12a765c509
Prior to this, -B would suppress the prompt for package rebuilding if
your Emacs version or hostname changed. Now, it fully inhibits
rebuilding in either case.
Fix: #7760
Ref: cff091982e
This removes the truncation of `package!` `:pin`s. This was originally
intended to make packages.el files easier to skim, but in hindsight it
didn't really. It served little other purpose but to make it harder for
folks to interact with the :pin string.
Due to upstream changes in ivy-rich, +workspace/switch-to throws a
`wrong-type-argument listp leaf` error. As I plan to phase out Ivy
support (and the Ivy module) in the long term, I'll simply remove
ivy (and ivy-rich) integration in the workspaces module, rather than
update it.
Fix: #7499Fix: #7173