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'
I move our hackiest and least offensive startup optimizations to core,
so they're easy for me to keep track of (they'll likely change often,
between major Emacs releases), to keep them from affecting non-Doom
profiles, and make it easy for readers to use as a reference.
...that are always enabled. This way, the module API treats them as any
other module.
This also changes doom-module-load-path. If supplied directories,
doom-user-dir will not be the CAR of its return value. If no dirs are
supplied, then doom-core-dir and doom-user-dir are included (and will
always be the first two items in the returned list).
For small amounts of data, symbol plists are the most efficient (space
and time wise) as data access gets in Emacs. Hash tables, though O(1),
impose a minimum threshold of overhead before it becomes the efficient
option, but this benefit won't be obvious for datasets of at least 60 or
less.
Since modulep! is used *a lot*, and used to determine a module's
state (and state of its flags), there is a benefit to caching it.
Still, this is only a read-only cache, and does not replace the
`doom-modules` hash-table, which will always be the preferred interface
for the rest of the module API.
Used to return the hash-table `doom-modules` (if not all-p), but I've
changed it to return a list of cons cells (:CATEGORY . MODULE),
representing all enabled modules, in the order they were enabled.
The purpose of this change is to prepare for a change in the structure
of doom-modules, and how Doom stores its module metadata.
- Rename doom-module-path -> doom-module-expand-path, to better reflect
its purpose.
- Optimize doom-module-locate-path to try caches and
locate-file-internal, before looping through doom-modules-dirs.
- Rely on file-name-concat to join paths, rather than string
concatenation. file-name-concat is more robust for the purpose and
has lower overhead than expand-file-name.
- Add a 27.x check, recommending that users upgrade to 28.1.
- Removed the check for <27. Loading doom.el with sub-27 will already
fail with a detailed error about supported versions.
- Now detects development (.50) and pre-release (.9x) builds of Emacs,
and warns the user of their dangers.
- Revises the warning for 29+ or .50|.9x users.
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.
The debugger appears to display uninterned symbols properly, and since
these symbols should never be touched/referenced by users, there's no
reason to pollute the obarray with these transient symbols.
This file used to live in /.github/ci.el. It was later moved to
/.doomrc (in 9b8ed39), but I forgot to push this change to update the
relative path to Doom's modules. This caused the linter to complain that
all module scopes were invalid.
Also, I removed the $DOOMDIR/modules/ check, as modules in the user's
config shouldn't be factored into the list of valid scopes.
Amend: 9b8ed397e8
Rather than reimplement its face lookup (and have two versions of
doom-print-ansi-alist -- one for 27.x and one for 28+), let's just rely
on ansi-color.
This adds the basic framework of docs/examples.org, including the former
contents of demo.org in :lang emacs-lisp. elisp-demo has also been
reconfigured to search it instead.
Keep in mind that examples.org references a few things in as-of-yet
published documentation. This will be rectified soon.
This was adapted from
https://www.reddit.com/r/emacs/comments/d7x7x8/finally_fixing_indentation_of_quoted_lists/.
It fixes the indentation of quoted data (and plist keywords) so they're
indented like data, rather than function arguments, like so:
BEFORE:
`(foo bar baz
doom emacs)
'(:foo 1
:bar 2
:baz 3)
'(:foo 1
2
3
:bar 4)
(:foo 1
:bar 2)
(:foo 1
;; test comment
:bar 2)
(:foo 1
2
:bar 3)
AFTER:
`(foo bar baz
doom emacs)
'(:foo 1
:bar 2
:baz 3)
'(:foo 1
2
3
:bar 4)
;; only align unquoted keywords if keywords start each line:
(:foo 1
:bar 2)
(:foo 1
;; test comment
:bar 2)
(:foo 1
2
:bar 3)
Also, I added a way to declare that plists in an macro's arguments
should be indented like data:
(put 'map! 'indent-plists-as-data t)
BEFORE:
(map! :localleader
:map emacs-lisp-mode-map
(:prefix ("d" . "debug")
"f" #'+emacs-lisp/edebug-instrument-defun-on
"F" #'+emacs-lisp/edebug-instrument-defun-off))
AFTER:
(map! :localleader
:map emacs-lisp-mode-map
(:prefix ("d" . "debug")
"f" #'+emacs-lisp/edebug-instrument-defun-on
"F" #'+emacs-lisp/edebug-instrument-defun-off))
There was a third improvement I was hoping to include, namely,
proper indentation of interpolated forms:
BEFORE:
`(foo
bar
,(if t
'baz
'boo))
`(foo
bar
(if t
baz
boo))
AFTER:
`(foo
bar
,(if t
'baz
'boo))
`(foo
bar
(if t
baz
boo))
But this was removed because it breaks indentation for quoted macro
forms (or dynamic elisp programming):
BEFORE: (good)
`(with-temp-buffer
(if (always)
(message
"Hello %s"
user-login-name)
(message
"Goodbye %s"
user-login-name)))
AFTER: (bad)
`(with-temp-buffer
(if (always)
(message
"Hello %s"
user-login-name)
(message
"Goodbye %s"
user-login-name)))
Ref: https://www.reddit.com/r/emacs/comments/d7x7x8/finally_fixing_indentation_of_quoted_lists/'
These only benefit interactive sessions, and doom-start's responsibility
is to configure interactive sessions; it doesn't make sense to keep
these in core.
This refactors how Doom captures and redirects its output (to stdout and
stderr) into a more general with-output-to! macro, and:
- Simplifies the "print level" system. The various doom-print-*-level
variables have been removed.
- Adds a new print level: notice, which will be the default level for
all standard output (from print!, doom-print, prin[ct1], etc).
- Adds a with-output-to! macro for capturing and redirecting
output to multiple streams (without suppressing it from stdout). It
can also be nested.
- Changes the following about doom-print:
- Default :format changed to nil (was t)
- Default :level changed to t (was `doom-print-level`)
- No longer no-ops if OUTPUT is only whitespace
This commit reduces the debug log noise, makes it easier to
read/parse/search, and soft-introduces a convention for doom-log
messages, where they are prefixed with a unique identifier loosely named
after it's running context or calling function.
I haven't enforced it everywhere doom-log is used yet, but this is a
start.
BREAKING CHANGE: This removes the doom-incremental-load-immediately
variable. Instead, set doom-incremental-first-idle-timer to 0 to force
all iloaded packages be eagerly loaded at startup. This is already the
default behavior for daemon sessions.
BREAKING CHANGE: If anyone is using Doom's CLI framework and are
defining their own CLIs with any of the following macros, they'll need
to be updated to their new names:
- defautoload! -> defcli-autoload!
- defgroup! -> defcli-group!
- defstub! -> defcli-stub!
- defalias! -> defcli-alias!
- defobsolete! -> defcli-obsolete!
These were renamed to make their relationship with CLIs more obvious;
they were too ambiguous otherwise.
BREAKING CHANGE: This performs the following backwards-incompatible
changes:
- Replaces `+emacs-lisp-reduce-flycheck-errors-in-emacs-config-h` with a
`+emacs-lisp-non-package-mode` minor-mode.
- Removed the `+emacs-lisp-disable-flycheck-in-dirs` variable, as this
mechanism no longer checks a directory list to detect a "non-package".
If you've referenced either of these symbols, you'll need to
update/remove them from your config. No extra config is needed
otherwise.
Why: Doom has always tried to reduce the verbosity of Flycheck when
viewing elisp config files or scripts (i.e. non-packages). These are so
stateful that the byte-compiler, package-lint, and checkdoc inundate
users with false positives that are more overwhelming than helpful.
The heuristic for this has always been a simple "is this file in
$DOOMDIR or $EMACSDIR", but this wasn't robust enough, especially in
cases where symlinking was involved, so I've employed a new, more
general heuristic for detecting non-package files:
- The file isn't a theme in `custom-theme-load-path`,
- The file doesn't have a (provide ...) or (provide-theme ...)
statement whose first argument matches the file name,
- The file lives in a project with a .doommodule file (doom modules
never have convention package files in them),
- Or the file is a dotfile (like .dir-locals.el or .doomrc).
I've also tweaked byte-compile-warnings to yield a little more output,
but not by much. Whether this is too permissive or not will require
further testing to determine.
What's more, I've updated this to reflect recent changes to Doom's
startup process (in c05e615).
Ref: c05e61536e
While fixing #6772, we also address several other issues found by
sh-shellcheck:
L47C39 SC1007:Remove space after = if trying to assign a value
(for empty string, use var='' ... ).
L47C46 SC2046:Quote this to prevent word splitting.
L62C20 SC2086:Double quote to prevent globbing and word splitting.
L82C9 SC2154:tmpdir is referenced but not assigned
(did you mean 'TMPDIR'?).
When trying to establish the value of EMACSDIR, the proper fallback
when BASH_SOURCE is undefined is $0 rather than 0, in correct shell-
scripting parlance.
With mu4e came a new face for the header view. While this is nice for
the text, it had the consequence of making the account stripe (the
vertical bar) a bit jarring. This patch fixes that behavior to make the
stripe non-italic by append `'default` to the face.
The nix-mode package already does this and it shadows other entries for the .drv files in auto-mode-alist (namely Guix derivations).
Ref: 34d51e2731/nix-drv-mode.el (L48)
Necessitated by 7e0c2ed, and missed in 45a66cd. This would indirectly
cause "No :repo specified for package 'X'" errors for packages with a
`:local-repo` relative to their packages.el file.
Amend: 45a66cda60
Ref: 7e0c2ed8a3
In v3, doom-module data is stored in symbol plists, but in v2, it's
stored in a hash table. Some v3 code snuck into 45a66cd, which made Doom
try to read module data from plists that hadn't been initialized yet, so
Doom could no longer see your module settings.
Fix: #6769
Amend: 45a66cda60
Otherwise, doom-module-from-path (and modulep!) would fail to detect the
module they're in, or at least, modulep! would incorrectly return nil,
even for enabled modules.
This issue is what would've caused the package list or the doctor to
include/consider packages in disabled modules or behind disabled flags.
Writing a debugger for Elisp is too much hassle. `debug` itself isn't
very customizable without a *lot* of boilerplate, so instead of writing
my own, it's more effective to advise debug instead. Certainly, I don't
do anything with it yet, but I will soon.
