Doom is slowly transitioning away from requiring that its doom-*-dir
variables end in a slash (see two refs below), but there are some
vestiges of it left. This is one of them.
Fix: #6842
Ref: 00e8f6b72a
Ref: b914830403
The `if` clauses were swapped, such that a non-symlinked path was shown
like,
~/.config/emacs/ -> ~/.config/emacs/
and a symlinked path was shown as,
~/.config/emacs/
* lisp/cli/help.el (doom help): move to lisp/cli/meta.el, and add :dump
definition.
* lisp/doom-cli.el:
- (doom-before-init-hook): trigger hook after the file is done
loading.
- (doom-cli-backtrace-depth, doom-cli-straight-error-lines,
doom-cli-benchmark-threshold): rename these variables' prefix from
`doom-cli-` to `doom-cli-log-`.
- (doom-cli--plist): rename to doom-cli--group-plist, to better clue
in what changes it.
- (doom-cli-context-parse): remove unused letbind (argsleft).
- (doom-cli-create-context-functions, doom-cli-before-run-functions,
doom-cli-after-run-functions): define with defcustom instead of
defvar, to indicate that they are (especially) intended for end-user
configuration.
$EMACSLOADPATH is read to pre-fill load-path. Empty entries therein are
substituted with the default value of load-path. I am mirroring this
behavior with the $DOOMPATH variable.
A regression introduced in 4efaf68, cause by an incomplete refactoring
of the loop, where not all instances of `key` were changed into `group`
and `name`.
Amend: 4efaf6837bFix: #6840
This is a regression introduced in 1c4217a.
Doom unsets command-line-x-option-alist when it reasonably suspects it's
not running in an X environment. The heuristic for that is checking when
`initial-window-system` is set to `x`, but as it turns out, PGTK builds
of Emacs set this to `pgtk`, so PGTK users were deprived of Emacs' X
switches, like --geometry, --foreground, --font, etc (they'd throw an
"Unknown option" error at startup). This was fixed.
However, this heuristic isn't perfect. Not all PGTK users are on X (I'd
hazard to guess most of them aren't). So a more reliable check is
needed (and it's too early in the startup process for us to call
display-graphic-p on any frame). The `(not IS-LINUX)` or `(or IS-MAC
IS-WINDOWS)` I had previously used (before 1c4217a) wasn't enough
either, because users can (and do) install X on these
systems (especially where WSL is involved). Still, until I've found a
better one, this is an acceptable workaround.
Amend: 1c4217aa27
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
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}}.
Due to $DOOMPROFILE being set to an empty string when persisting Doom
CLI sessions, which would affect any case where a CLI command restarts
the session (e.g. when the :config literate module tangles a config or
'doom --debug ...' restarts to set DEBUG=1).
What used to be a `byte-compiled-config` trait, displayed in your `M-x
doom/info`, is now `compiled-user-config`, `compiled-core`, and
`compiled-modules`, for more helpful granularity for debugging possible
byte-code issues.
Due to a technical limitation of Emacs <=28, launching Emacs out of a
non-standard location is non-trivial, and `doom run` tries to promise
that it can do so on demand. Emacs 29 does introduce a --init-directory
switch that would make this easy, but it'll be some time before we can
rely on it.
So 'doom run' creates a fake $HOME in /tmp/doom.run/ and writes a
bootloader there to load your Doom config remotely. But there's a
problem: in this fake $HOME, none of the user's config, cache, data, or
binscript directories are available, so I symlink them there. This
should at least resolve the most trivial incompatibilities (like the
lack of all-the-icons fonts, which typically get installed to
$HOME/.local/share/fonts/ -- see #6807), but there may be yet more edge
cases. Still, this is a good enough compromise for now.
Fix: #6807
In 4a25375, it seemed that only setting the variables to nil early
enough would be sufficient, but this turned out not to be the case.
There's no avoiding calling the mode to disable it.
Ref: 58c0de6841
Amend: 4a253757cb
