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'
There are some conventional files strongly associated with a non-bash
shell which do not use an explicit `.zsh` file extension (e.g.
`.zprofile`); the old logic would always use the `#!/usr/bin/env bash`
shebang in these cases, which is a tiny little bummer.
doom-etc-dir will be renamed to doom-data-dir, to better reflect its
purpose, and align it with XDG_DATA_HOME (where it will be moved to in
v3, where Doom will begin to obey XDG directory conventions more
closely).
- Deprecates the doom-private-dir variable in favor of doom-user-dir.
- Renames the pseudo category for the user's module: :private -> :user.
- Renames the doom-private-error error type to doom-user-error.
Emacs uses the term "user" to refer to the "things" in user space (e.g.
user-init-file, user-emacs-directory, user-mail-address, xdg-user-dirs,
package-user-dir, etc), and I'd like to be consistent with that. It also
has the nice side-effect of being slightly shorter. I also hope
'doom-user-error' will be less obtuse to beginners than
'doom-private-error'.
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.
To reduce redundancy, remove the maintenance hassle that version
constants would impose later on, and rely on built-in
facilities (featurep) more over global variables or doomisms, these
global constants have been deprecated in favor of Emacs "features":
- EMACS28+ -- replace with (> emacs-major-version 27)
- EMACS29+ -- replace with (> emacs-major-version 28)
- NATIVECOMP -- replace with (featurep 'native-compile)
- MODULES -- replace with (featurep 'dynamic-modules)
(These constants will be formally removed when v3 is released. The IS-*
constants are likely next, but I haven't decided on their substitutes
yet)
I also decided to follow native-compile's example and provide features
for Emacs' system features (since system-configuration-features' docs
outs itself as a poor method to detect features):
- dynamic-modules
- jansson
- native-compile -- this one already exists, but will instead be removed
if it's non-functional; i.e. (native-comp-available-p) returns nil.
These are now detectable using featurep, which is fast and built-in.
This adds an alternative backend to the :ui vc-gutter module, enabled
with the +diff-hl flag. In the future, I intend for diff-hl to replace
git-gutter, as it is slightly faster and depends on more native
functionality (vc.el), but it's still a little buggy. It will remain
opt-in until those issues are sorted out.
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
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.
doom-debug-p and doom-interactive-p have always been intentionally
redundant, because changing the variables they replaced had other
side-effects, which made writing tests for them difficult. Since our
new (yet unpublished) tests lean heavily toward integration testing more
than unit testing, this becomes an implementation detail.
And doom-init-p's only use was refactor out at some point in the past,
so it's no longer used.
Also done to reduce Doom's footprint, in general.
as opposed to a nasty error,
the error was raised because I was not using the abs of count
this commit also comes with general code cleanup,
this includes
- removal of the eval quasiquote antipattern when an apply would work
better
- use of the :key keyword instead of the lambda
This basically stops the "not overlay" error we were getting when you
tried to jump to many times. this does have the disadvantage of not
jumping at all if the amount of jumps is higher than the amount of
overlays but this can be fixed in a future commit if necessary.
Changes:
- add +fold--ts-fold-p which only checks if the feature is around
- add ts-fold into +fold/toggle, +fold/open, +fold/close
- update doc strings
Defining `*-any-quote` objects via the exiting `*-block` helpers leads
to incorrect behaviour, where the trailing boundary is also included as
part of the selection (cursor on `|`, selection between `|`):
```
start: "te|st"
v i q: "|test"|
```
The expected behaviour is the same as `v i "`:
```
start: "te|st"
v i q: "|test|"
```
Fix: #5698
Change how we detect and suppress file template expansion in org-capture
buffers (which are indirect clones). Since 99.99% of the time, an
indirect clone means we're doing something special in that buffer, it
seemed sensible to always suppress file templates in them. Hopefully
this will be more robust than the former advice.
As described at https://www.json.org/json-en.html, JSON has multiple
top-level forms (at least objects and arrays, and potentially all values
as well, depending on who you ask). Of these, I would not say array is a
good default. I frequently find myself deleting this default, generally
to use an object instead.
Because there is no consistent winner, and because the template is so
trivial, it seems best to simply delete it: the cost of the template not
matching the user's intent outweighs any benefit it stands to deliver
when it does match the user's intent.
