Doom loaded subdirs.el's in `load-path`, but doesn't need to. This
normally wasn't an issue because subdirs.el files are typically
idempotent, but there is one case where it isn't: on nixpkgs, with
certain configurations on top of programs.emacs (see
NixOS/nixpkgs#267548), which will cause file-missing errors trying to
load the user's site-lisp afterwards (see #7681).
Ref: NixOS/nixpkgs#267548Fix: #7681
Amend: 6c0b7e1530
If the target directory wasn't in a project, this command would throw a
type error (see #8032).
This also adds more checks and informative error handling to the
command.
Fix: #8032
"C-i" and "TAB" are equivalent to Emacs. In GUI Emacs, we can bind to
[tab] instead of "TAB", permitted users to treat the two keys
differently. However, [tab] is unavailable in TTY frames, so there was
no avoiding sacrificing C-i keybinds there. With KKP support, though,
that's no longer the case.
BREAKING CHANGE: This moves helpful.el out of core into :lang
emacs-lisp. Since most (all) people have this module enabled, this
shouldn't make a difference for most people, but if you're one of the
few that don't have :lang emacs-lisp enabled, Doom will revert to using
Emacs' built-in help.el and describe-* commands.
Others can also disable helpful with (package! helpful :disable t) if
they prefer Emacs' built-in help system, which wasn't possible before,
because it was a core package.
This was done as part of an ongoing effort to slim down Doom's core in
preparation for v3.
sxhash doesn't guarantee hashes are consistent across Emacs sessions, so
use md5 instead. Also simplifies what's getting hashed;
`system-configuration` is a sufficient substitute for both `system-type`
and what I wanted to glean from changes in
`system-configuration-features`.
Amend: 80e9263b85Close: #8030
Ref: #8024
Co-authored-by: yaaama <yaaama@users.noreply.github.com>
A change upstream was causing recursive load errors. I'm not too clear
how it happens, as I can't reproduce it, but
bbatsov/projectile@3c92d28c05 is the common thread (bumped in
c1b5f48).
Rather than revert the bump, I've just undone the hook and used a saner
hook for the same task. It is a stopgap solution until I eventually
replace projectile with project.el.
Ref: bbatsov/projectile@3c92d28c05
Amend: c1b5f48f07
Should fix issues where modes/hooks weren't triggered for
files/directories opened early (e.g. from the command-line or
programmatically from the user's config).
A user's shell config might destructively alter the shell's $PATH (also
common on MacOS, which destructively sets $PATH with its system dotfiles
for ZSH). This prevents the sub-shell spawned from `doom/reload` and
`doom/upgrade` from inheriting emacs' `$PATH`, which Doom adds
$EMACSDIR/bin to. Without this entry, these commands would fail to find
the Doom script.
Fix: #8027
Amend: a8ba8feecb
Turns out native-comp doesn't respect
`native-comp-jit-compilation-deny-list` if called explicitly (instead of
from deferred compilation).
Fix: #5592Fix: #6283Fix: #3655
Avoid installing a newer (or older) and possibly incompatible copy of
seq.
Also, seq would get installed along with its unit tests, and Emacs will
hang trying to natively compile them, so...
Eventually, Emacs will process any files passed to it via the command
line, and will do so *really* early in the startup process. These might
contain special file paths like TRAMP paths (e.g.
/sudo://etc/ssh/ssh_config), so restore `file-name-handler-alist' just
for this small portion of startup.
These uses of this macro are a micro optimization that yield no benefit.
The only place it's useful is in autoloads (which are guaranteed to be
byte-compiled during `doom sync`).
There are still a few edge cases where inhibit-redisplay is never
reset (usually involving errors at startup), leaving Emacs as a blank
screen until the user performs an action that forces it to redraw (e.g.
pressing M-x). This tries to address more of those.
I introduced '--ignore-file .project' to `projectile-git-fd-args` in
4fcf332 expecting fd to ignore the file if it didn't exist, but it
throws an error if it doesn't, causing it to throw these errors in any
project without a .project file.
Amend: 4fcf332749
Reverts projectile-project-root-files-bottom-up to its original value,
since the absence of those VC entries may surprise folks who aren't new
to projectile.
I intend to eventually replace projectile with project.el, so these
doom-projectile-* variables need to be generalized, starting with the
fd/ripgrep executable paths.
ALong with that, this refactors Doom's projectile-generic-command to
lean more on built-in fd support in projectile, where possible (fewer
wheels reinvented).
Ref: doomemacs/core#1
I intend to keep `project-vc-extra-root-markers` much lighter than what
`projectile-project-root-files` ended up being, so I won't be
transferring all the root markers.
Ref: doomemacs/core#1
Allow ahead-of-time native-compilation during CLI operations that
install or update packages. This will not retroactively native-compile
already-installed packages, you'll need to use --rebuild to do so.
(This is a stop-gap solution until the v3.0 release)
Fix: #6811
When running `doom sync --rebuild` after emacs upgrade the user is
prompted with "Installed packages must be rebuilt. Do so now?", even
though doom was explicitly instructed to rebuild. This PR removes this
prompt when the `--rebuild` option is provided
Showing `user-init-file` in the startup message seems more confusing
than helpful, especially to beginners, as it's not a file they can (or
should) be editing to fix whatever caused the error. Plus, its value
could be `t` if the error happens late enough in the startup process,
which is even less helpful.
Before this, text that extended past the new line's length would
persist, causing garbled output like this:
> Ensuring packages are installed and built...
> Updating recipe repos...
> Cloning org-appear...r emacsmirror-mirror...
- No packages need attention
Which might lead you to believe org-appear is being cloned from
emacsmirror-mirror, but the full output is actually:
> Ensuring packages are installed and built...
> Updating recipe repos...
> Updating recipes for melpa...
> Updating recipes for nongnu-elpa...
> Updating recipes for gnu-elpa-mirror...
> Updating recipes for el-get...
> Updating recipes for emacsmirror-mirror...
> Cloning org-appear...
- No packages need attention
