BREAKING CHANGE: Removes magit-todos from the magit module. I've always
thought my choice to include it as a 'reasonable default' in this module
was a bit dubious. Given how trivial the config is, I leave it to users
to install if they want it, instead.
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
Apheleia's default config for prettier adds --use-tabs/--tab-width to
force prettier to match Emacs' indent settings, which is fine until a
prettier config file tries to overwrite it and is ignored. As a
compromise (and stopgap solution), I omit these flags if any prettier
settings are set in the current project.
Fix: #7998
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>
These uses of this macro are a micro optimization that yield no benefit.
The only place it's useful is in autoloads (which are guaranteed to be
byte-compiled during `doom sync`).
popen is a dependency of flymake-popen, and is on nongnu-elpa, which
wasn't supported by straight until recently, so the package! statement
is no longer needed.
Ref: 71469d8056
Due to the nested structure of eglot-server-programs, our advice would
not correctly detect entries for some modes (like javascript modes),
effectively disabling Eglot in those modes.
I've replaced the advice with a solution baked into lsp!, so folks still
have the option of using eglot-ensure directly if they want it activated
unconditionally.
Amend: #7219
Reduces edge cases, in the case the user eagerly loads any of these
packages. Also replaces all hardcoded paths to ocp-indent and opam's
executables with variables, respecting user configuration.
The ocamlformat.el package reinvents what Apheleia is already doing, but
Apheleia's default definition for ocamlformat is a little simplistic.
This merges the efforts of both and allows us to cut down on an unneeded
dependency.
The "clangd" package links to the version of clangd associated with that
version of the distribution. In Debian 11 it's clangd-11, in 12 it's
clangd-14, Ubuntu 22.04 LTS also has clangd-14, and 23.10 seems to have
clangd-16. No need to specify the clangd package name for each release.
Ref: #7502
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
I intend to keep `project-vc-extra-root-markers` much lighter than what
`projectile-project-root-files` ended up being, so I won't be
transferring all the root markers.
Ref: doomemacs/core#1
