- Rename doom-module-path -> doom-module-expand-path, to better reflect
its purpose.
- Optimize doom-module-locate-path to try caches and
locate-file-internal, before looping through doom-modules-dirs.
- Rely on file-name-concat to join paths, rather than string
concatenation. file-name-concat is more robust for the purpose and
has lower overhead than expand-file-name.
- Add a 27.x check, recommending that users upgrade to 28.1.
- Removed the check for <27. Loading doom.el with sub-27 will already
fail with a detailed error about supported versions.
- Now detects development (.50) and pre-release (.9x) builds of Emacs,
and warns the user of their dangers.
- Revises the warning for 29+ or .50|.9x users.
It's not useful in those scenarios, and is more likely to throw up
unrecoverably keybind conflict errors, when load order is determined by
an over-eager byte-compiler, rather than Doom's standard startup
process.
The debugger appears to display uninterned symbols properly, and since
these symbols should never be touched/referenced by users, there's no
reason to pollute the obarray with these transient symbols.
Rather than reimplement its face lookup (and have two versions of
doom-print-ansi-alist -- one for 27.x and one for 28+), let's just rely
on ansi-color.
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 refactors how Doom captures and redirects its output (to stdout and
stderr) into a more general with-output-to! macro, and:
- Simplifies the "print level" system. The various doom-print-*-level
variables have been removed.
- Adds a new print level: notice, which will be the default level for
all standard output (from print!, doom-print, prin[ct1], etc).
- Adds a with-output-to! macro for capturing and redirecting
output to multiple streams (without suppressing it from stdout). It
can also be nested.
- Changes the following about doom-print:
- Default :format changed to nil (was t)
- Default :level changed to t (was `doom-print-level`)
- No longer no-ops if OUTPUT is only whitespace
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.
BREAKING CHANGE: If anyone is using Doom's CLI framework and are
defining their own CLIs with any of the following macros, they'll need
to be updated to their new names:
- defautoload! -> defcli-autoload!
- defgroup! -> defcli-group!
- defstub! -> defcli-stub!
- defalias! -> defcli-alias!
- defobsolete! -> defcli-obsolete!
These were renamed to make their relationship with CLIs more obvious;
they were too ambiguous otherwise.
Necessitated by 7e0c2ed, and missed in 45a66cd. This would indirectly
cause "No :repo specified for package 'X'" errors for packages with a
`:local-repo` relative to their packages.el file.
Amend: 45a66cda60
Ref: 7e0c2ed8a3
In v3, doom-module data is stored in symbol plists, but in v2, it's
stored in a hash table. Some v3 code snuck into 45a66cd, which made Doom
try to read module data from plists that hadn't been initialized yet, so
Doom could no longer see your module settings.
Fix: #6769
Amend: 45a66cda60
Otherwise, doom-module-from-path (and modulep!) would fail to detect the
module they're in, or at least, modulep! would incorrectly return nil,
even for enabled modules.
This issue is what would've caused the package list or the doctor to
include/consider packages in disabled modules or behind disabled flags.
Writing a debugger for Elisp is too much hassle. `debug` itself isn't
very customizable without a *lot* of boilerplate, so instead of writing
my own, it's more effective to advise debug instead. Certainly, I don't
do anything with it yet, but I will soon.
Emacs 27.x does not collapse consecutive slashes in a file path when
trying to load them, and instead discards everything before it and
treats the rest as an absolute path, e.g. "~/some//path/foo/" ->
"/path/foo". This is not the case in 28.1, but Doom's backport of
file-name-concat did not take this into account, so it's been modified
to trim trailing slashes.
Fix: #6766
Amend: 433c9e344d
This is caused by a bug in recent builds of Emacs 29, where
`loaddefs-generate` will activate emacs-lisp-mode to read a package's
autoloads, but does so without suppressing its mode hooks. Other
packages may add functions to this hook from their autoloads (like
overseer.el does). Calling these functions will initiate a chain
reaction where other packages will be loaded (plus their dependencies),
but aren't guaranteed to be available so early in the bootstrap process.
The result are file-missing errors about seemingly unrelated packages,
like pkg-info or dash.
Ref: emacs-mirror/emacs@0d383b592c
Fix: https://discourse.doomemacs.org/t/3149
Occurs when a site-file fails to be natively compiled, and Doom attempts
to write an error file in the same directory. On some systems, the
site-lisp directory is in a read-only tree/mount (like nix and guix).
This should suppress those attempts.
Relying on eval-after-load's compiler-macro magic (after 8b4f722) can
cause scope issues with nested macros (like file! and dir! running in
the context of a temp buffer), so best we use with-eval-after-load
directly.
Ref: 8b4f722fa3
To ensure that they're expanded at a file's top-level, while expanded,
where they're used. It also fixes a few inlined uses of the file!
macro (e.g. in `load!`, as reported in #6764), which was prematurely
committed ahead of this change.
Close: #6764
Amend: a179b8d262
b7f84bd introduced a nasty regression that caused an infinite loop and
runaway memory usage on some pgtk+native-comp builds of Emacs when it
attempted to perform deferred native compilation of your packages. This
would make Emacs unusable and, if left alone, could even crash your
system.
The only Emacs builds I'm certain are affected are derived from
flatwhatson/emacs (like emacs-pgtk-native-comp on Guix and Arch Linux in
particular). 28.1 stable and master (on emacs-mirror/emacs@e13509468b)
are unaffected.
It appears that some, earlier pgtk builds stack idle timers differently.
I'm not entirely sure how, because it doesn't manifest in more recent
builds of Emacs, and I'm already burnt out on debugging this, but here's
how Doom encountered it:
Doom has an incremental package loader; it loads packages, piecemeal,
after Emacs has been idle for 2s, then again every 0.75s until it
finishes or the user sends input (then it waits another 2s before
starting again). However, if at any time the iloader detected that
native-compilation is in progress, it waits 2s before trying
again (repeat, until native-comp is done). But here's the catch, given
the following:
(run-with-idle-timer
2 nil (lambda ()
(run-with-idle-timer 1 nil (lambda () (message "hi")))))
I had assumed "hi" would be emitted after 3 seconds (once idle), but
instead it is emitted after 2. Like this, Doom's iloader would elapse
one idle timer directly into another, ad infinitum, until Emacs was
forcibly killed.
By switching to run-at-time and employing my own rudimentary idle timer,
I avoid this issue. Also, the iloader no longer needs to be considerate
of native-comp, because the latter does its own rate-limiting controlled
by native-comp-async-jobs-number.
Amend: b7f84bdd01
This allows us to load them via doom-require. Why not use normal
features? Because Doom's libraries are designed to be loaded as part of
Doom, and will openly rely on Doom state if needed; this is a contract I
want to enforce by ensuring their only entry points are through
`doom-require` or autoloading.
I will add them to the rest of the libraries later.
Site-node: this also adds Commentary+Code to the comment headings, as I
want a space to use that space to describe the library, when I get
around to it.
These functions are light wrappers around require and load, such that
Doom will catch (and decorate) any errors from the target file, and is
also capable of loading Doom's subfeatures.
This is a regression from 948f946, where a bunch of mkdir calls were
removed prematurely. In v3, other processes are responsible for creating
these directories, but those haven't been implemented yet.
Fix: #6756
Amend: 948f9461a7
If doom-emacs-dir contains a "~", attempting to call `git -C` will fail
with an error like:
fatal: cannot change to '~/.config/emacs/': No such file or directory
Fix this by canonicalizing the filename.
I prefer to be more explicit about these variables' defaults, then to
rely on proper load order and unverified global state to ensure they're
properly set.
