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
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
"C-i" and "TAB" are equivalent to Emacs. In GUI Emacs, we can bind to
[tab] instead of "TAB", permitted users to treat the two keys
differently. However, [tab] is unavailable in TTY frames, so there was
no avoiding sacrificing C-i keybinds there. With KKP support, though,
that's no longer the case.
BREAKING CHANGE: This removes git-gutter as an implementation for the
`:ui vc-gutter` module, leaving only the diff-hl implementation. There
are no longer any +git-gutter or +diff-hl flags for this module. Users
don't have to do anything to keep the vc gutter, unless they prefer
git-gutter for any reason (in which case they'll need to install and set
it up themselves).
This has been planned for some time, because of a roadmap goal for Doom
to lean into native/built-in functionality where it's equal or better
than the third party alternatives. diff-hl relies on the built-in vc.el
library instead of talking to git directly (thus expanding support to
whatever VCS's vc.el supports, and not git alone), which also means it
can take advantage of its caching and other user configuration for
vc.el. Overall, it is faster and lighter.
What I've also been waiting for was a stage-hunk command, similar to
git-gutter:stage-hunk, which arrived in dgutov/diff-hl@a0560551cd and
dgutov/diff-hl@133538973b, and have evolved since.
Ref: dgutov/diff-hl@a0560551cd
Ref: dgutov/diff-hl@133538973b
Ref: https://github.com/orgs/doomemacs/projects/5/views/1?pane=issue&itemId=58747789
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
With this commit, now you can define any key to `doom-locallleader-map`
symbol and it will work as expected. The `which-key` descriptions will
work as expected too. The only caveat is that the localleader map is now
updated using hooks so there the potential for bugs where the incorrect
map is selected.
This commit moves leader key descriptions from
`which-key-replacement-alist` to the keymap itself. This helps with
performance because that way, which-key does not have to calculate every
single leader key description for each keypress. Furthermore, this fixes
issues like #1413 where relocating leader keymaps resulted in which-key
not showing the correct leader key descriptions.
I also made the leader prefix maps have their own prefix commands by
populating the function slot of the keymap variables. This is an Emacs
convention. I made `doom-leader-map` follow this convention as well.
* lisp/doom-cli.el:
- reference backport source commit.
- doom-cli--restart: a type check is all we need here. This is a
programmer error, not a user error.
* lisp/doom-editor.el (recentf): mention recentf-show-abbreviated (added in
emacs-mirror/emacs@32906819ad)
* lisp/doom-keybinds.el (doom-init-leader-keys-h): move to
doom-after-init-hook, in case the user customizes leader variables in
a previous hook (like emacs-startup-hook or after-init-hook).
* lisp/doom-start.el: use eval-when! to compile out the section on
non-macOS systems (when Doom gets around to compiling its core files,
later).
* modules/config/literate/autoload.el (+literate-config-file): use
file-name-concat instead of string concat. This relaxes the
requirement that doom-user-dir end in a /; a requirement I intend to
fully phase out.
* modules/lang/emacs-lisp/autoload.el (+emacs-lisp-non-package): remove
empty map! macro in flycheck-emacs-lisp-check-form. The macro already
no-ops at compile-time/in noninteractive sessions since b480ed51a3.
* modules/ui/hl-todo/config.el (hl-todo-keyword-faces): revise
commentary for default hl-todo keywords.
Ref: emacs-mirror/emacs@32906819ad
Ref: b480ed51a3
BREAKING CHANGE: For consistency and correctness, I've renamed the
module init/config hooks, and added new ones:
- Adds doom-before-modules-config-hook
- Adds doom-after-modules-config-hook (replaced doom-before-init-modules-hook)
- Adds doom-before-modules-init-hook
- Adds doom-after-modules-init-hook (replaced doom-init-modules-hook)
- Removed doom-after-init-modules-hook (replaced w/ after-init-hook)
The old naming (and timing) was counterintuitive. Now, it's named after
the loaded file group (init.el vs config.el), and I added before/after
variants. Altogether, this should make them less ambiguous.
I've also moved some functions in various modules to more correct hooks.
Load order before this change:
- $EMACSDIR/early-init.el
- $EMACSDIR/lisp/doom.el
- $EMACSDIR/lisp/doom-start.el
- $DOOMDIR/init.el
- {$DOOMDIR,~/.emacs.d}/modules/*/*/init.el
- `doom-before-init-modules-hook'
- {$DOOMDIR,~/.emacs.d}/modules/*/*/config.el
- `doom-init-modules-hook'
- $DOOMDIR/config.el
- `doom-after-init-modules-hook'
- `after-init-hook'
- `emacs-startup-hook'
- `window-setup-hook'
Load order after this change:
- $EMACSDIR/early-init.el
- $EMACSDIR/lisp/doom.el
- $EMACSDIR/lisp/doom-start.el
- $DOOMDIR/init.el
- `doom-before-modules-init-hook'
- {$DOOMDIR,~/.emacs.d}/modules/*/*/init.el
- `doom-after-modules-init-hook'
- `doom-before-modules-config-hook'
- {$DOOMDIR,~/.emacs.d}/modules/*/*/config.el
- `doom-after-modules-config-hook'
- $DOOMDIR/config.el
- `after-init-hook'
- `emacs-startup-hook'
- `window-setup-hook'
It's not useful in those scenarios, and is more likely to throw up
unrecoverably keybind conflict errors, when load order is determined by
an over-eager byte-compiler, rather than Doom's standard startup
process.
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.
doom-enlist is now a deprecated alias for ensure-list, which is built
into Emacs 28.1+ and is its drop-in replacement. We've already
backported it for 27.x users in doom-lib (in 4bf4978).
Ref: 4bf49785fd
BREAKING CHANGE: This restructures the project in preparation for Doom
to be split into two repos. Users that have reconfigured Doom's CLI
stand a good chance of seeing breakage, especially if they've referred
to any core-* feature, e.g.
(after! core-cli-ci ...)
To fix it, simply s/core-/doom-/, i.e.
(after! doom-cli-ci ...)
What this commit specifically changes is:
- Renames all core features from core-* to doom-*
- Moves core/core-* -> lisp/doom-*
- Moves core/autoloads/* -> lisp/lib/*
- Moves core/templates -> templates/
Ref: #4273
