$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.
* 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
