It's kind of a pain to have different behavior when you're debugging.
Some errors may not present without them, so best to remain predictable
and permit these optimizations even when debug mode is on.
defcustom does some initialization work to accommodate the possibility
that the user has set the variable before it was defined. This work is
unneeded so early at startup, so I disable it (temporarily).
In the future, Doom will use defcustom more, as it's a helpful
indication to readers what variables I intended for configuration (and
helps with discovery of options through `M-x doom/help-custom-variable`
or `M-x customize`). As that transition occurs, the benefit of this
optimization will begin to show, but for now its effect on startup time
is negligible.
* lisp/doom.el (warning-suppress-types): set this immediately. Since its
default value is nil and this happens so early at startup, we don't
have to be considerate of defaults. Plus, this custom-dont-initialize
optimization can cause breakage if a warning is thrown *before* before
this setting is changed.
Where f9201eb introduced a general context system, this one introduces
one for modules, to simplify our let-bind game when interacting with
modules, and to more efficiently expose module state to modulep! (which
gets called at runtime a great deal, so its performance is important).
* lisp/doom-lib.el (doom-log): simplify macro and introduce
doom-inhibit-log variable.
* lisp/doom-modules.el (modulep!): fix reported file path if modulep!
fails to find the local module.
* lisp/lib/debug.el (doom-debug-variables): disable doom-inhibit-log
when debug mode is on.
Ref: f9201eb218
load! effectively loads (file-name-concat (dir!) PATH) which, in this
case, is concatenating two absolute file paths. Emacs does the right
thing and loads PATH, but I don't want to rely on this good fortune as
it could be broken in a future update.
Introduces a system to announce what execution contexts are active, so I
can react appropriately, emit more helpful logs/warnings in the case of
issues, and throw more meaningful errors.
* bin/doom: load module CLIs in the 'modules' context.
* lisp/cli/doctor.el: load package files in 'packages' context.
* lisp/doom-cli.el:
- (doom-before-init-hook, doom-after-init-hook): trigger hooks at the
correct time. This may increase startup load time, as the benchmark
now times more of the startup process.
- (doom-cli-execute, doom-cli-context-execute,
doom-cli-context-restore, doom-cli-context-parse,
doom-cli--output-benchmark-h, doom-cli-call, doom-cli--restart,
doom-cli-load, run!): remove redundant context prefix in debug logs,
it's now redundant with doom-context, which doom-log now prefixes
them with.
* lisp/doom-lib.el (doom-log): prefix doom-context to doom-log output,
unless it starts with :.
* lisp/doom-packages.el (package!, doom-packages--read): throw error if
not used in a packages.el file or in the context of our package
manager.
* lisp/doom-profiles.el (doom-profile--generate-init-vars,
doom-profile--generate-load-modules): use modules doom-context instead
of doom-init-time to detect startup.
* lisp/doom-start.el (doom-load-packages-incrementally-h): move function
closer to end of doom-after-init-hook.
* lisp/doom.el:
- (doom-before-init-hook, doom--set-initial-values-h,
doom--begin-init-h): rename doom--set-initial-values-h to
doom--begin-init-h and ensure it runs as late in
doom-before-init-hook as possible, as that is the point where Doom's
"initialization" formally begins.
- (doom-after-init-hook): don't trigger at the end of command-line-1
in non-interactive sessions. This will be triggered manually in
doom-cli.el's run!.
* lisp/lib/config.el (doom/reload, doom/reload-autoloads,
doom/reload-env): use 'reload' context for reload commands.
* modules/lang/emacs-lisp/autoload.el (+emacs-lisp-eval): use 'eval'
context.
* modules/lang/org/config.el: remove doom-reloading-p; check for
'reload' doom context instead.
* 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
* lisp/doom-lib.el:
- (fn!): unroll the loop into a single, fast setplist that
doesn't require a cl-lib macro (autoloading which seems to throw an
error on flatpak/snap builds; still investigating that one).
- (add-transient-hook!): Removes a redundant let-bind. `sym` is
already lexically bound outside the function. This will break
anywhere lexical-binding is nil though. Not sure if I should cater
to that scenario...
- Adds doom-module-packages-file and doom-module-metadata-file.
- Uses them and the other doom-module-*-file variables where they were
previously hardcoded.
- Add .el extension to doom-module-{init,config}-file; it is now the
consumer's responsibility to strip/change/keep the extension as they
see fit.
I intend to phase out the internal usage of use-package in Doom's core
and modules. The macro is too complex and magical for our needs.
That said, until we've fully removed it, this :config use-package is
hardcoded to be enabled-by-default, until use-package has been
refactored out of core and modules. It'd be wise not to add it to your
doom! blocks yet.
This introduces a depth field for modules so that they may dictate their
load order explicitly, it also treats depths <= -100 or >= 100 as
special depths, which will be loaded early, before their respective
doom-{before,after}-module-{init,config}-hook. This permits psuedo
modules like :core and :user modules to be treated as normal modules
without too many special cases.
This also fixes a module load order issue on Emacs 29 (#6813), caused by
emacs-mirror/emacs@4311bd0bd7, which changed the return value order of
hash-table-{keys,values} causing modules to be loaded in reverse order;
resulting in the loss of evil keybinds, among other things.
Other notable changes:
- Changes the data structure for module data caches from a list to a
vector. Uses less memory and permits faster lookups. Also adds two
depth fields to the front of it.
- Changes the signature of doom-module-list and doom-package-list.
- Renames doom--read-packages -> doom-packages--read for consistency
with naming convention.
- Add doom-module-depth function.
- Adds a temporary doom-core-dir/init.el file, which is responsible for
loading doom-*.el.
Fix: #6813
Ref: emacs-mirror/emacs@4311bd0bd7
When the *IRC* workspace is already populated by circe buffers, there is
no reason to emit an error, just switch to the *IRC* workspace and do
nothing.
+mu4e-lock-available seems like a potential entry-point to the mu-lock
functionality, e.g. on startup check if another Emacs process has mu4e
active, and so it might as well be turned into an autoload.
Originally this was added to have the order of attached files match the
order of mark selection. Recent usage indicates that this was either
misguided or the behaviour has changed, as this now achieves the opposite
effect --- with nreverse files are attached in reverse order. Removing
nreverse provides the expected behaviour.
It's a bit silly to just unconditionally widen the current frame when
you could have the mu4e headers view in another frame entirely. Instead
we can look for the mu4e headers buffer, and only widen frames where it
is the active buffer.
When using evil +everywhere, we disable the default forge bindings.
We must then explicitly remap magit-browse-thing, as it's just a
placeholder command (bound in multiple places).
While this is a hidden buffer, it's raised when an error occurs. In such
situations, it can be a little confusing to see the result of every
tangle to date instead of just the last tangle. It's easy enough to
simple clear the buffer at the start of the tangle process.
An unintended change snuck into 2c14eff. The :core and :user virtual
modules are no longer stripped from the module list before iterating
through (and loading) them. This meant that Doom would load these two
like regular modules (and first, since these two are always at the start
of the list).
This is harmless for :core, because it has no init.el or config.el, but
:user does! This means $DOOMDIR/{init,config}.el would be loaded
twice (once before all other modules and again afterwards), causing load
order issues (like #6818).
Fix: #6818
Amend: 2c14eff7f1
- Batch more variables in Doom's autoloads files.
- Remove all the register-definition-prefixes calls generated in
autoloads files (for both modules' and packages' autoloads). These
don't serve much purpose, and only incur added cost growing a large
hash table.
Any buffers created before after-init-hook could trigger these hooks,
which may house expensive functions, but never anything that is
important at startup time.
However, it must not occur later than after-init-hook (which triggers
before file arguments are processed and file buffers are created).
To understand this issue, you have to understand these two things:
1. Doom builds an init file which combines all its autoloads (for
packages and modules), and Doom's bootstrapper (which loads modules,
$DOOMDIR, etc). This init file is byte-compiled.
2. When Emacs byte-compiles elisp, docstrings are lazy-loaded (by
embedding them in the elc as commented text to be retrieved later).
This is generally done to save on memory.
Now the issue: when these lazy-loaded docstrings are retrieved, Emacs
may evaluate the whole file to find it, including Doom's bootstrap
process, reloading all its files, the user's config files, and running
all its startup hooks. Not only is this terribly expensive, reloading
these files may have disastrous effects.
One such effect is compounded by Marginalia, which invokes this
docstring fetch process (by calling the `documentation` function in
`marginalia--function-doc`) for *each* symbol in the `M-x` or `C-h
{v,f}` completion lists, which means Doom re-bootstraps multiple times
and rapidly, causing Emacs to totally lock up.
The solution is to simply gate the expensive part of the initfile so it
doesn't run more than once, at startup, and when `doom/reload` is
called. The rest of the file loads instantly.
Still, this is a bit flimsy. I'll think of a more elegant solution
later.
- Since its arguments aren't used, make the advice n-arity, to future
proof the advice.
- Add commentary on load's side-effect on user-init-file.
- Add NOSUFFIX arg to load call, to spare Emacs the file IO of searching
for init.%d.elc{.{so{,.gz},elc{,.gz},el{,.gz},,gz}}.
