Because this file serves as a global manifest for Doom's profiles, it
should be kept in a central location for any Doom instance to consult,
rather than per-instance. Plus, post-v3 Doom will only write files to
$XDG_*_HOME and $TMPDIR, therefore I'd like to avoid writing to
$EMACSDIR.
This change shouldn't affect end-users, in any case. Run 'doom sync' to
regenerate the file, which should happen when you run 'doom upgrade'
anyway.
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.
With the comma syntax. E.g.
(let ((maps '(some-mode-map another-mode-map)))
(map! :map ,maps))
This technique was used in the recent rewrite of the Racket
module (1baebda), but I forgot to include this change, so Racket users
have probably noticed some missing keybinds! This fixes that too.
Amend: 1baebdafb3
Ref: #7543
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.
It seems there's an edge case in EXWM where input events may occur
without keys to cause them (#8064), so these two keybind fixes need to
be ready to receive an empty vector from `this-single-command-raw-keys`.
Fix: #8064
This was a tricky regression to track down. 9753bfb tries to fix an
issue where the `default` face's :foreground changes to `#000000` in any
new frames created after the initial one (by calling `make-frame`),
because those frames' `background-color` and `foreground-color`
parameters default to "#000000" (possibly a bug with `disable-theme` too
eagerly defaulting them to black).
240493a replaces that with new, seemingly cleaner approach: setting
`frame-inherited-parameters`, which instructs `make-frame` to copy those
parameters from the last open frame, however, those parameters in the
initial daemon frame will be set to "unspecified-bg" or
"unspecified-fg" (see the docstring for `face-{back,fore}ground`), which
are invalid color strings. `make-frame` crashes tries to create a frame
with those color values, causing #8059.
Fix: #8059
Amend: 240493ae92
Amend: 9753bfb775
Those `face-*` calls sometimes returned nil, causing new frames spawned
from emacsclient to quietly crash sometimes. By instead relying on
`frame-inherited-parameters` we achieve the same but more stable result.
Amend: 9753bfb775
Now, uses can rebind ctrl+m by targeting [C-m] (or "<C-m>", same thing),
and it won't rebind RET. This will only work in GUI Emacs, however, and
there is no kkp support for this one.
Ref: 96d7e50f3e
Experienced users (the type to use symlinks in their projects) can add
-L back to `projectile-git-fd-args`, otherwise, its poorer UX for
beginners if Projectile indexes symlinked build artifacts (like 'result'
symlinks by Nix); i.e. things they didn't symlink themselves.
Fix: #7781
Instead of constantly checking $__DOOMSH, since I may eventually add
additional values for it (like in the cases where the doom script is
invoked by bin/doomscript, from a terminal emulator in Emacs, or future
wrappers).
