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
- Move Doom core elisp API demos out of docs/examples.org into lisp/demos.org.
- Recognize and search demos.org file in modules for additional
demos (including $DOOMDIR/demos.org).
- Refactor emacs-lisp module to use new elisp-demos-user-files variable
instead of an advice. This way, elisp-demo's commands (such as
`elisp-demos-find-demo` and `elisp-demos-add-demo`) will include
Doom's demos.
