Some were outdated, some were incorrectly labeled, others were already
completed, some were missing... Gotta fix them all.
Also, in :ui hl-todo, there are comments that describe how Doom uses
each of these annotations; those have been updated.
And use it to replace the various `posframe-delete-all` hooks littered
about to clean up child/posframes in contexts where they may linger
after destructive operations (like changing the active workspace or
executing `doom/reload`).
There's little reason for users to use these macros in their private
configs over plain ol' `with-eval-after-load` and `use-package`, unless
they're writing their own modules.
It's my fault for signal boosting them in documentation and whenever I'm
asked for help, because beginners now believe they are somehow
required for Doom to work correctly (there are guides out there
telling beginners that migrating to Doom involves replacing all
instances of `with-eval-after-load` and `use-package` in their
pre-existing configs with `after!` and `use-package!` -- which was never
true).
What's more, I plan to replace `use-package`, internally, so the
`use-package!` macro won't exist for much longer.
Treat paths as paths, rather than strings. Removes the requirements that
doom-*-dir variables end in slash (though I'll continue doing so as a
convention). Also moves a lot of cache/data into the current profile's
cache/data directories. Shouldn't actually affect anything for folks not
using Doom's profile system (yet).
Fix: #8616
This is due to `counsel-projectile-switch-project` not initializing the
known projects list before consulting the `projectile-known-projects`
variable (or at the very least, calling the function of the same name,
rather than referencing the variable directly). By changing
counsel-projectile-remove-current-project, it now does.
In the interest of slimming down Doom's core (as we near v3), I've
deprecated these macros. They doesn't really need to exist. Sure, the
alternatives aren't as ergonomic or elegant, but they're good enough
that we don't need these trivial wrappers. Their local uses have been
refactored out as well.
BREAKING CHANGE: This backports some architectural choices from v3.0.
This changes Doom's module API, renaming some functions and removing
others, in order to facilitate some new features, prepare to move Doom's
modules into separate repos, and make way for two, much larger breaking
commits coming in the next few days.
This commit won't break anything for users unless they're tinkering with
Doom's internals/using its `doom-module-*` API directly. I am avoiding
broader backwards incompatibilities until the 3.0 release.
What's new:
- Negated flags. (modulep! :editor evil -everywhere) will return non-nil
if :editor evil is active without its +everywhere flag.
- `modulep!` now takes multiple flags to simplify AND checks. E.g.
(and (modulep! +foo)
(modulep! +bar)
(not (modulep! +baz)))
Can now be expressed with:
(modulep! +foo +bar -baz)
- Adds pcase matchers for `doom-module-context` and `doom-module`
structs, making the following destructuring binds possible:
(pcase-dolist ((doom-module group name flags features)
(hash-table-values doom-modules))
...)
This will be used more in v3.0.
- Adds file cookie support to module init.el and config.el files.
Here's a summary of breaking changes made in this commit:
- `doom-module-context` was changed from a vector to a struct (record).
- `doom-modules` is now a table of `doom-module` structs, rather than
free-form plists.
- The following macros have been renamed:
- `doom-context-with` -> `with-doom-context`
- `doom-module-context-with` -> `with-doom-module`
- The followings functions have been replaced/removed:
- `doom-module-context`+`doom-module-context-get` -> `doom-module`
- `doom-module-set` -> `doom-module--put`
- `doom-module-p` -> `doom-module-active-p`
- `doom-module-context-key` (is now a getter with the same name)
- `doom-module-put` (removed)
- `doom-module--context-field` (removed)
- The signatures for these functions have changed:
- `doom-module-get CATEGORY &optional MODULE PROP` ->
`doom-module-get (GROUP . MODULE) &optional PROP`
- `doom-module-locate-path CATEGORY &optional MODULE FILE` ->
`doom-module-locate-path (GROUP . MODULE) &optional FILE`
- `doom-module-expand-path CATEGORY MODULE &optional FILE` ->
`doom-module-expand-path (GROUP . MODULE) &optional FILE`
- Adds the following functions
- `doom-module-exists-p`
- `doom-module-key`
- `doom-module->context`
- `doom-module<-context`
- Removes the following variables
- `doom-module--empty-context`
This commit results in a little redundancy, which I will address in
parts 2/3 and/or v3.0.
These optional dotfiles indicate the root of a module or module
group (:lang), and will later contain module metadata. They will also
serve as an alternative to packages.el and doctor.el, and will aide the
parts of the v3.0 module API concerned with resolving the current module
from a path (`doom-module-from-path`), which currently rely too heavily
on parsing path strings.
For now, however, they're simply placeholders.
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.
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
Ivy is practically Vertico's spiritual successor, and its module is one
of the more higher-maintenance modules in our library. Rather than
maintain two spiritually identicaly modules, I'd rather focus on the
better one.
I won't make any moves to actually remove the Ivy module until well
after the v3 release, when `doom sync` and `doom upgrade` have rollback
functionality, and those commands are better equipped to warn uses about
module deprecations (and we have our new Github Discussions board set
up, so we have a centralized place to announce them).
Monkey-patches counsel-rg to ignore non-zero exit codes. This may have
other side effects, but despite it still producing workable resutls, the
command will discard all its results if there are any errors while
scanning a directory.
Ref: abo-abo/swiper#2339
Fix: #3038
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.
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
Depending on the system, this can cause sorting to be disabled long
before the performance hit would be felt, and it's not obvious that this
is the reason.
These modules tend to conflict if more than one of them are enabled at
once. More systematic compatibility tests are in the works, but for now
this will do.
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
Overriding `ivy--flx-featurep` here would always prevent flx from being
loaded and enabled---even if it were `t`---because ivy `require`s it in
`ivy--flx-featurep`'s initvalue. So instead, this sets the variable if
and only if it should be disabled. Because flx isn't installed when
+prescient is enabled, I've included that in the condition for disabling
ivy--flx-featurep as well
Fix: https://github.com/doomemacs/doomemacs/issues/6034
Amend: bae7ab0d8d
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.
I've omitted docs/*.org from this merge, as there is still work left to
do there, but I am pushing the module docs early so folks can benefit
from the new docs sooner.
