`startup--load-user-init-file` persists its original
user-emacs-directory in a lexical binding that we cannot affect from
early-init.el, and uses it to find init.el. This prevents non-Doom
profiles' init.el files from being loaded.
A way around this is to have our own $EMACSDIR/init.el that loads
{user-emacs-directory}/init.el, but that's unnecessary work and ruins
our users' ability to use their $EMACSDIR as their $DOOMDIR, so I opted
for advice instead, to force it to recognize the changed
user-emacs-directory.
Fix: https://discourse.doomemacs.org/t/3251
To quote `user-emacs-directory`'s docstring:
> Note that this should end with a directory separator.
However, users may forget to add one in their profile configs, which
will cause errors.
Fix: #6608
Some time ago I noticed the cooperative lock file management wasn't
working as I remember. I forget what exactly I was thinking, but
basically I've poked at the code until it seems to work better.
It's possible for these hooks to be triggered recursively, such as in
the case of emojify's "Emoji images not available should I download them
now?" prompt (reported upstream).
Fix: iqbalansari/emacs-emojify#100
Fix the handling of a nil path within doom/delete-this-file.
If path is nil (e.g. called interactively when buffer is not visiting a
file), avoid calling abbreviate-file-name on nil, otherwise an error
will be signaled:
(wrong-type-argument stringp nil)
Additionally, fix the subsequent path checks. These were treating two
distinct scenarios as a "Buffer is not visiting any file" user-error:
- nil path
- non-existent path
- Only the first should result in that error. The second should proceed
to the next path check (which was previously unreachable), to signal
the appropriate error, "File doesn't exist: %s".
In 4d9ea6853b I reacted to a either a change that I presume occurred
in org-msg at some point, or behaviour originally unnoticed, that led to
bulk-selected files being attached in reverse. Further investigation has
indicated that this isn't actually making attachment order work as
expected, just hiding the reverse behaviour from bulk-attachment. The
better approach is to keep the dired mark reversal, and change
org-msg-attach-attach to add new files to the end, not the start, of the
list of attachments.
There are two changes to the default optional read-file-name arguments
that should be made for the purpose of attaching files:
1. The optional MUSTMATCH argument should be set, as one can't exactly
attach non-existent files.
2. The INITIAL argument should be set to the empty string so that if
default-directory is customised for some reason or another that
selecting it leads to the expected directory being selected.
Without INITIAL or DEFAULT-FILENAME being specified, the current file
path will be used, which is never desirable as this is simply a path
to the message buffer.
Replace the rather crude "don't do anything if already in a mu4e-y
buffer" behaviour with a more refined approach that tries to find the
live mu4e buffer likely of the most interest and switch to that, before
calling (mu4e) if no such buffer is found.
A mistake in 5a5195b caused modules without an explicit :depth to be
loaded in the wrong order (because their final depth wasn't cached
correctly, and so were all given a depth of 0, thus falling back on
their insertion order, which is precisely what 5a5195b was trying to
fix). This commit fixes that and changes the module cache vectors to
match the structure of doom-module-context, for consistency.
Amend: 5a5195b84dFix: #6813Fix: #6859
This macro used to be `doom-with-context`, but was renamed in the middle
of backporting f9201eb218, but these references were missed.
Fix: #6849
Amend: f9201eb218
The doctor would look for stale byte-code in *all* build directories,
which was excessive and produced many false positives for folks who use
multiple versions of Emacs or have recently up/downgraded.
doom-module-from-path fails to deduce the module from some paths (it
seems to struggle with doom-user-dir in some cases), causing a (aref nil
2) error (see #6845).
Fix: #6845
Occurs during non-interactive startup of the user's config (e.g. 'doom
doctor'), while :ui (modeline +light) is enabled.
This is a makeshift solution until I get around to finishing the +light
feature.
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.
If lisp/doom.el does not exist, then we assume the user isn't loading a
Doom config and fall through to $EMACSDIR/early-init.el, if it exists.
However, `load`'s NOERROR argument suppresses more than just
file-missing errors -- it suppress permissions errors and other
legitimate IO errors that I want to treat as error states, not
fall-through states. This commit fixes that.
* early-init.el (gc-cons-threshold): Set a reasonable more default for
gc-cons-threshold for non-Doom configs (16mb), instead of
most-positive-fixnum, which would eventually cause
freezing/stuttering for non-Doom profiles.
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.
