The performance benefit of doing so has always been questionable or, at
best, negligible, but has caused numerous issues over the years. The
latest one being #8162, where byte-compiling a profile init file with
too many package autoloads would consume more than 255 opcodes, causing
an overflow error.
For simplicity's sake, Doom will no longer byte-compile this file.
Fix: #8162
BREAKING CHANGE: This restructures Doom's core in an effort to slim it
down and partially mirror architectural changes coming in v3. This is
part 2 of 3 commits (part 1 being 1590434), done to facilitate a change
in part 3 that will introduce a new `doom!` syntax for pulling
third-party module libraries from remote sources (similar to `package!`
statements). I am backporting this from V3 so I can move our modules out
into separate repos sooner than later, so development on modules can
continue separately without interfering with v3's roll out.
Though this is labeled a breaking change, it shouldn't affect most users
except those few tinkering directly with Doom's internals.
Ref: 15904349cf
Should fix issues where modes/hooks weren't triggered for
files/directories opened early (e.g. from the command-line or
programmatically from the user's config).
These uses of this macro are a micro optimization that yield no benefit.
The only place it's useful is in autoloads (which are guaranteed to be
byte-compiled during `doom sync`).
Showing `user-init-file` in the startup message seems more confusing
than helpful, especially to beginners, as it's not a file they can (or
should) be editing to fix whatever caused the error. Plus, its value
could be `t` if the error happens late enough in the startup process,
which is even less helpful.
Doom inserts some expensive hooks in MODE-local-vars-hook, like
triggering LSP servers, tree-sitter, or visual enhancements -- things
that are unnecessary in temporary (invisible) buffers, so I suppress
them altogether there.
Before this, it was non-trivial to *truly* disable the menu-bar in GUI
frames on MacOS, unless you knew about the
doom-restore-menu-bar-in-gui-frames-h hook and removed it. With this
change, the hook will bow out if the user has tampered with/called
menu-bar-mode at all.
If the user uses the doom-load-packages-incrementally function directly,
and has set doom-incremental-first-idle-timer set to nil, it will throw
a type error.
Close: #7710
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
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
- 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.
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}}.
Moves this from doom-ui to doom-start, since there is more savings to be
had if this is done early.
Also moves the menu-bar fix for macos out of the :os macos module into
doom-start, because it is a fix (and for a Doom optimization) and not a
feature, so it shouldn't be behind a module.
BREAKING CHANGE: This commit makes three breaking changes:
- Doom now fully and dynamically generates (and byte-compiles) your
profile and its init files, which includes your autoloads, loading
your init files and modules, and then some. This replaces
doom-initialize-modules, doom-initialize-core-modules, and
doom-module-loader, which have been removed. This has also improved
startup time by a bit, but if you use these functions in your CLIs,
for instance, this will be a breaking change.
- `doom sync` is now required for Doom to see your profiles (and must be
run whenever you change them, or when you up/downgrade Emacs across
major versions).
- $DOOMDIR/init.el is now read much earlier than it used to be. Before
any of doom-{ui,keybinds,editor,projects}, before any autoloads are
loaded, and before your load-path has been populated with your
packages. It now runs in the context of early-init.el, giving users
freer range over what they can affect, but a more minimalistic
environment to do it in.
If you must have some logic run when all that is set up, add it to one
of the module hooks added in e08f68b or 283308a.
This also poses a significant change to Doom's load order (see the
commentary change in lib/doom.el), along with the following (non
breaking) changes:
1. Adds a new `doom profiles sync` command. This will forcibly resync
your profiles, while `doom sync` will only do so if your profiles
have changed.
2. Doom now fully and dynamically generates (and byte-compiles) your
user-init-file, which includes loading all your init files, modules,
and custom-file. This replaces the job of doom-initialize-modules,
doom-initialize-core-modules, and doom-module-loader, which have been
removed. This has also improved startup time by a bit.
3. Defines new doom-state-dir variable, though not used yet (saving that
and the other breaking changes for the 3.0 release).
4. Redesigns profile directory variables (doom-profile-*-dir) to prepare
for future XDG-compliance.
5. Removed unused/unimportant profile variables in doom.el.
6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's
enough to power the system as it is now.
7. Updates the "load order" commentary in doom.el to reflect these
changes.
The default-frame-alist properties are only necessary for the scrollbar.
The variables are enough for the rest. Also, no need to set
x-gtk-use-symtem-tooltips if we're turning off tooltips anyway.
Also moves the UI config that snuck its way into doom-start back to
doom-ui.
doom-before-init-hook runs before $DOOMDIR/init.el is loaded.
doom-after-init-hook runs at the *very* end of the Emacs startup
process (after 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.
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 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.
