- Remove +dired--suppress-hooks-in-previews-a, because Dirvish already
does this.
- Exploit dirvish-preview-environment instead of hardcoding the
enable-local-variables let-binding for the child process. Its defaults
are more reasonable.
Prior to this, I used window-width to determine whether file details
should be hidden, but there was a jarring delay on `dirvish-setup-hook`
that made the effect look awful (especially when walking up and down
file trees).
This changes `dirvish-hide-details` to accept a list of contexts where
it should be enabled, which I think is more elegant. Of course,
`dirvish-hide-details` will fall back on old behavior if set to `t` or
`nil`.
I'll consider upstreaming it later (and perhaps doing similar for
`dirvish-hide-cursor`).
Ref: #6760
Currently, setting `dirvish-use-mode-line` to nil blanks out the
mode-line, and setting it to `t` makes Dirvish use its own mode-line. To
get the default mode-line, `dirvish-mode-line-format` needs to be set to
nil, but even then Dirvish will prepend a bar to the default-mode-line
so it can control its height, which I think is a confusing chain of
causes and effects.
This changes the behavior such that `dirvish-use-mode-line` controls
whether `dirvish-mode-line-format` will be used or not. I'll upstream
this to hlissner/dirvish later.
Fix: #8000
BREAKING CHANGE: This drops the Dired module's +ranger flag and replaces
much of this module's innards with (my maintained fork of) Dirvish,
which provides a spiritually similar (if not superior) experience to
Ranger. Plus, Dirvish makes most of our dired plugins unnecessary.
Also, I am now registering myself as this module's maintainer now that I
dogfood and maintain Dirvish.
Close: #6760
Co-authored-by: alexluigit <alexluigit@users.noreply.github.com>
Co-authored-by: hpfr <hpfr@users.noreply.github.com>
Co-authored-by: LemonBreezes <LemonBreezes@users.noreply.github.com>
Co-authored-by: pharcosyle <pharcosyle@users.noreply.github.com>
I intend to eventually replace projectile with project.el, so these
doom-projectile-* variables need to be generalized, starting with the
fd/ripgrep executable paths.
ALong with that, this refactors Doom's projectile-generic-command to
lean more on built-in fd support in projectile, where possible (fewer
wheels reinvented).
Ref: doomemacs/core#1
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
magit/magit@97a95f7007 -> magit/magit@4881835572
The pinned version of `magit` in `:tools magit` needs be the same
as that of `git-commit` in `:emacs vc`.
`straight.el` prepares the repo only once, and if `git-commit` is
processed first, its pinned version wins out and the more recent
pinning of `magit` is ignored.
As noted in #7363, processing order may be non-deterministic, so the
inconsistent pinning may not be apparent on every system.
Fix: #7363
Amend: #7277
Amend: 7c63b353d2
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
Previously, only gitlab.com and gitlab.gnome.org were recognized as
gitlab hosts. This tweaks browse-at-remote to recognize any subdomain
named gitlab.* as a gitlab host (as a fallback, if no other regexp
matches).
This is provided by `smerge-mode` in Emacs 27, and functions exactly
like `smerge-next`, except that if there are no more conflicts in the
current file, it will go to the next file with conflicts.
Arguably this could be a different key binding. However, I find that it
is almost strictly superior to `smerge-next`: I can't think of a case
where I *wouldn't* immediately want to go to the next file with
conflicts, and even if you do by accident you can just pop back to the
preceding buffer. So I think it warrants being the default.
Close: #5431
alexluigit/dirvish@73dcaa404d -> alexluigit/dirvish@4fe9c00894
This "lateral" bump buys us more time until doomemacs/doomemacs#6760 lands.
`dirvish`'s repository apparently rebased the commit we have pinned.
Visiting it gives us:
```
This commit does not belong to any branch on this repository, and may
belong to a fork outside of the repository.
```
Te new pinned version references the same commit contents, but on a new
position. They're correctly identified as identical by git. The new
commit also contains an explicitly reference to the old one:
```
Former-commit-id: 73dcaa4
```
Ref: 73dcaa404d..4fe9c00894
featurep! will be renamed modulep! in the future, so it's been
deprecated. They have identical interfaces, and can be replaced without
issue.
featurep! was never quite the right name for this macro. It implied that
it had some connection to featurep, which it doesn't (only that it was
similar in purpose; still, Doom modules are not features). To undo such
implications and be consistent with its namespace (and since we're
heading into a storm of breaking changes with the v3 release anyway),
now was the best opportunity to begin the transition.
