12a765c introduced suppression of package-rebuilding prompts on 'doom
upgrade', but inadvertently reversed the check. This fixes that (and
refactors the if/or tree into a `cond`).
Amend: 12a765c509
Prior to this, -B would suppress the prompt for package rebuilding if
your Emacs version or hostname changed. Now, it fully inhibits
rebuilding in either case.
Fix: #7760
Ref: cff091982e
'doom purge' is now deprecated.
Also changes 'doom sync's -p option to --gc. Since GCing causes the loss
of historical data, I'd rather it be a long option to make it a little
harder to do accidentally.
This changes 'doom sync' to be smarter about responding to changed
package recipes/pins, changes in Emacs version, or instances where the user
has copied a config to a new system.
In all these cases, the user would formerly have to know about a
specific combination of 'doom sync -u' and 'doom build' to ensure Doom
is in a good state. With this change, 'doom sync' handles all these
cases.
Also, 'doom build' is now deprecated (and 'doom sync' now has a
--rebuild option to mimic its old behavior).
Also also, sometimes, a package may silently fail when cloned (which
used to result in an empty repo). Now, if this is detected, cloning will
be re-attempted up to 3 times before aborting with much more visible
error.
Note: these are stopgap solutions, until v3 is finished.
Something often reported are file-missing errors when a package that
should be present isn't. This can easily happen if, say, during a 'doom
sync' or 'doom upgrade' a package fails to clone correctly and the user
misses the errors, then tries to carry on as normal. What's worse is
that Straight leaves behind an empty directory, which it treats as a
sign that the package has been cloned correctly, so it doesn't raise any
fuss over them.
With this change, 'doom sync' (and 'doom upgrade') will now try again,
if the clone process fails the first time (up to 3 times) before
aborting the whole process altogether, which should be loud enough for
users not to miss. Note that these failures at 99.99% because of
network (or upstream downtime) issues.
For now, this does leave Doom in an incomplete state (until you try
again when the connection issue is resolved), but a rollback step will
be added in v3 to prevent this, as well as better error messages (as
well as @doomelpa mirror for packages on less reliable hosts, like
codeberg, savannah, etc).
BREAKING CHANGE: This removes the 'doom compile' and 'doom clean'
commands, and offers no immediate replacement for them (and no plan to
include one). In the future, byte-compilation of Doom's internals will
be baked into 'doom sync', but until then, Doom is not optimized to take
advantage of byte-compilation, and forcing it provides no benefit.
Before this, startup optimizations were disabled in debug mode, but more
often than not, this just made it difficult to reproduce some errors at
startup.
One various OSes, Emacs ships with site-lisp files that load
OS/architecture-specific config (like native-comp config), or load-lines
for Emacs packages installed via your OS package manager (like mu4e).
Output from these are rarely suppressed, for some reason, which causes
noise in *Messages* at startup, which triggers a redraw, which can be
very expensive during startup, depending on your window system.
Due to a suppressed void-variable error, font initialization is
short-circuited across daemon frames when the fonts are reloaded or
changed (which is also triggered by changing themes), resulting in
malformed (often tiny) fonts in GUI frames.
Fix: #7730
In some contexts, like org-agenda-switch-to visiting a TODO in an agenda
file, the visiting command will move the cursor after opening the file.
If save-place moves the cursor yet again, the cursor will end up in an
unpredictable place.
Some site files will forcibly undo `inhibit-message` or set
`force-load-messages`. This ensures site lisp files don't make
unnecessary noise at startup.
Tools like these will be moved to a benchmark module later (or perhaps
to `:lang emacs-lisp`). For the time being, it only takes up extra space
that few users use.
I will slowly phase out projectile in favor of project.el, starting with
projectile-find-other-file, which -- as of Emacs 29 -- has a native
alternative: `find-sibling-file`.
Ref: doomemacs/community#1
If the user uses the doom-load-packages-incrementally function directly,
and has set doom-incremental-first-idle-timer set to nil, it will throw
a type error.
Close: #7710
Currently, `SPC b k` does not allow us to kill popup buffers. If we are
say using a comint/eshell/eat buffer and we borked the state while
testing hooks or we sent EOF to the underlying process, our intention
with `SPC b k` is to kill the underlying buffer.
Recently, org-mode made a non-standard tab-width an error state.
Unfortunately, it's way too easy for users to accidentally change
it (e.g. with editorconfig, indiscriminate setter hooks, or other
packages), and since there is zero reason to ever want a non-standard
tab-width in org-mode, I not only exclude it from dtrt-indent as a
global default (i.e. not only as part of :lang org), but I add a late
org-mode-hook hook to reset tab-width, just in case.
Due to our inhibit-redisplay hack, a missing font could lead to a blank
Emacs after startup. This change fixes that so that not only is an error
emitted when Emacs can't find your font, but the error will be a little
more readable.
This is a stopgap solution until I finish a better one I'm preparing for
v3.
Fix: #7055
Changes what major modes we exclude from dtrt-indent's auto-detection.
Any mode in doom-detect-indentation-excluded-modes, plus derived modes,
will be excluded instead of only the parent modes.
This indirectly fixes an issue where org-mode derivatives (like
org-journal-mode) have their tab-width changed (#7670), causing the
`org-current-text-column` macro to throw the following error:
Tab width in Org files must be 8, not N. Please adjust your
`tab-width' settings for Org mode.
I opted for this solution instead rather than adding all possibly
derivatives to `doom-detect-indentation-excluded-modes`.
Fix: #7670
Ref: 38dd882685/lisp/org-macs.el (L1154)
It's possible for the user to type shell variables (something like
`$MYVAR/dir/filename`) as part of the filepath, so we need to call
`expand-file-name`.
When +vertico/find-file-in was replaced in 60e22fd with
+vertico/consult-fd-or-find, it changed a key behavior for
doom-project-find-file for Vertico users: instead of displaying an
initial list of all files under the target directory, it would display
nothing until the user entered in N * `consult-async-min-input`
characters, causing confusion (see linked comment).
Since Vertico integration modifies project-find-file-in's interface
appropriately, I leave it to that command instead.
Ref: https://github.com/doomemacs/doomemacs/issues/7312#issuecomment-1933404444
Amend: 60e22fd2eb
If $DOOMPATH is malformed or set to a value that does not contain a
valid path to Doom's CLI library in $EMACSDIR/lisp/cli (see #7608),
bin/doom no longer functions, emitting "a subcommand is required"
errors.
This change ensures that the CLI library is always the last (implicit)
element in doom-cli-load-path, and ensures $DOOMPATH is never written to
the user's envvar file (in case they try to use bin/doom from inside a
terminal within a Doom Emacs session), which should ensure users -- at
least -- never find themselves stranded without the Doom CLI.
Fix: #7608
Co-authored-by: bpizzi <bpizzi@users.noreply.github.com>
I began phasing out all-the-icons in 9787022. Now that Doom has
no (first order) dependencies that depend on it (and enough time has
passed), it's time to remove it.
Ref: 9787022b83
