While fixing #6772, we also address several other issues found by
sh-shellcheck:
L47C39 SC1007:Remove space after = if trying to assign a value
(for empty string, use var='' ... ).
L47C46 SC2046:Quote this to prevent word splitting.
L62C20 SC2086:Double quote to prevent globbing and word splitting.
L82C9 SC2154:tmpdir is referenced but not assigned
(did you mean 'TMPDIR'?).
When trying to establish the value of EMACSDIR, the proper fallback
when BASH_SOURCE is undefined is $0 rather than 0, in correct shell-
scripting parlance.
With mu4e came a new face for the header view. While this is nice for
the text, it had the consequence of making the account stripe (the
vertical bar) a bit jarring. This patch fixes that behavior to make the
stripe non-italic by append `'default` to the face.
The nix-mode package already does this and it shadows other entries for the .drv files in auto-mode-alist (namely Guix derivations).
Ref: 34d51e2731/nix-drv-mode.el (L48)
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
This is a regression from c05e615. doom.el changes user-emacs-directory
to doom-cache-dir, which may not exist yet, at the time of this check,
causing file-attributes to return nil, and causing = to throw a type
error (see #6754).
In addition to fixing this, I've also made the check more liberal about
failures, in the odd case that doom-emacs-dir, too, does not exist at
the time bin/doom is called (it'd be very hard to pull that off, but not
impossible).
Fix: #6754
Amend: c05e61536e
6c0b7e1 introduced a new convention for CLIs defined by Doom's modules:
to namespace them under `doom +MODULE ...`. What was once 'doom
everywhere' is now 'doom +everywhere', so the docs needed correcting.
Ref: 6c0b7e1530
BREAKING CHANGE: Racer is no longer developed and its project page
recommends using rust-analyzer instead. Moreover, users have reported
issues trying to build/install it on recent versions of rust, so I've
removed support for Racer from Doom, and now default solely to LSP for
IDE features.
Users that want these features will need to activate the module's +lsp
flag (along with the :tools lsp module) and install rust-analyzer. See
the module's README for instructions.
Close: #6705
Co-authored-by: c1ttim <c1ttim@users.noreply.github.com>
