From this point on, Straight will download packages from tarballs (if
possible) from their associated forge rather than clone them as git
repositories. This is (marginally) faster and consumes significantly
less space. Doom treats its packages as build artifacts anyway.
This shouldn't cause any immediate breakage, but it may upset folks who
want their local package installs to be repositories. For them, this can
be reversed by simply adding this to $DOOMDIR/init.el:
(after! doom-straight
(setq straight-vc-use-snapshot-installation nil))
This only applies to packages installed after this point. Packages that
are already cloned as a repo will stay that way until the next time
they're uninstalled or reinstalled from scratch. Plus it only works on
systems that have `tar` in their $PATH *and* forges that are
supported (at the time of writing: github, gitlab, codeberg, bitbucket,
and sourcehut).
Ref: radian-software/straight.el@4241b63952
When you fail to provide a correct commit message, it may just become
lost without this adjustment.
(fun fact: this feature was used to fix its own commit message 4 times)
In v3, 'doom run' will have a different purpose (for launching project
or CI/CD tasks), so it now emits a warning that it's moved to a new
'doom emacs' command.
I refrain from updating documentation because a rewrite of our docs will
be coming up soon.
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.
Like Fish, using nushell as your shell-file-name can cause downstream
issues wherever Emacs (or Emacs packages) spawn child processes via a
shell command and rely on its output. For example: diff-hl users may not
see a git gutter if nushell (or fish) is their $SHELL.
cli/gc.el accidentally snuck into 5e84709, along with a particular
v3-isms that doesn't belong in Doom yet, such as autoloads in CLI libs
and them providing subfeatures of doom-cli, rather than doom-cli-*.
These have been reversed for now.
Amend: 5e84709577
`letenv!` is a layover from the days before
`with-environment-variables` (introduced in 28.x), and it remained
afterwards because I preferred the shorter name. From v3 and onward,
Doom's core will be put on a diet which, among other things, will
include culling redundant or superfluous functions/macros like this one.
Many users seem to treat `doom/reload` like a 1-to-1 replacement for
`doom sync` + restart Emacs (which it is not), and are surprised when it
fails to properly "reload" their config. I'm considering removing
`doom/reload` altogether for this reason, or turning it into a light
wrapper around `restart-emacs`, but for now I'll settle for recommending
it less in documentation and comments. The references in docs/*.org will
be dealt with later.
Freeing this up to use for a future command (doom init), and because
'doom install' ought to be used very rarely and deliberately, so it
shouldn't have a convenient alias anyway.
BREAKING CHANGE: This restructures Doom's core in an effort to slim it
down and partially mirror architectural changes coming in v3. This is
part 2 of 3 commits (part 1 being 1590434), done to facilitate a change
in part 3 that will introduce a new `doom!` syntax for pulling
third-party module libraries from remote sources (similar to `package!`
statements). I am backporting this from V3 so I can move our modules out
into separate repos sooner than later, so development on modules can
continue separately without interfering with v3's roll out.
Though this is labeled a breaking change, it shouldn't affect most users
except those few tinkering directly with Doom's internals.
Ref: 15904349cf
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.
Eventually, I want to autoload some of this stuff, so that users in
interactive sessions can safely load it without side effects (useful
when writing their own CLIs or editing Doom's source).
sxhash doesn't guarantee hashes are consistent across Emacs sessions, so
use md5 instead. Also simplifies what's getting hashed;
`system-configuration` is a sufficient substitute for both `system-type`
and what I wanted to glean from changes in
`system-configuration-features`.
Amend: 80e9263b85Close: #8030
Ref: #8024
Co-authored-by: yaaama <yaaama@users.noreply.github.com>
Turns out native-comp doesn't respect
`native-comp-jit-compilation-deny-list` if called explicitly (instead of
from deferred compilation).
Fix: #5592Fix: #6283Fix: #3655
