Otherwise, undo could delete entire chunks of a shell buffer. This
addresses the issue in eshell, comint shells, and derivatives (like
ielm, shell, or inferior-* shells).
Ref: #8410
This makes the output of previous commands and prompts immutable (by
default), so users can't accidentally alter them, which can leave the
buffer in a half-broken state (requiring the user flush out the garbled
input with a couple RETs).
This targets comint shells (shell, ielm, etc), eshell, (ansi-)term, and
any derivatives thereof.
Fix: #8411
This functionality falls under the umbrella of "better defaults" rather
than essential defaults, and so belongs in :config default.
Whats more, the naming convention (+emacs-...) was intentional, because
this function (and the :config default module) will be moved to :doom
emacs in the near future.
This also indirectly fixes#8373.
Fix: #8373
Since we disable tooltip-mode, the echo-area should expand to display
multi-line output, to be consistent with our default for
resize-mini-windows. This also fixes the truncation of annotations in
PDF buffers (#1615).
Fix: #1615
Due to a typo in the hook's self-removal, causing this function to
trigger many times per second. It isn't doing much thanks to the
debouncing, but was still legitimately triggering doom-switch-frame-hook
every ~2 seconds despite no change in frame focus.
Also removes the ineffectual inhibit-redisplay let-bind.
Amend: 653b465c74
Redesign this hook around `after-focus-change-function`, along with
debouncing, to prevent it from triggering too aggressively (due to
misbehaving desktop environments, elisp packages that tinker with frame
focus, or accidental (and rapid) focus changes by the user).
`doom-switch-{window,buffer}-hook` have also been simplified, and
`doom-switch-window-hook` now will not trigger when focusing another
frame (only when you switch windows *within* any one frame).
This also fixes diff-hl not updating when refocusing an Emacs frame.
In the interest of slimming down Doom's core (as we near v3), I've
deprecated these macros. They doesn't really need to exist. Sure, the
alternatives aren't as ergonomic or elegant, but they're good enough
that we don't need these trivial wrappers. Their local uses have been
refactored out as well.
Users shouldn't be using both, and `load-theme` should be higher
priority (because it's easier to do by accident).
Fix: #8257
Amend: #8119
Amend: 50b9afbb2d
Instead of advising load-theme, which was more opinionated, and broke in
instances where users (relying on `custom-enabled-themes`s setter) or
packages (like auto-dark) were enabling themes with `enable-theme`
instead of `load-theme`.
This also adds support for enabling multiple themes with `doom-theme`.
Fix: #8119
This was a tricky regression to track down. 9753bfb tries to fix an
issue where the `default` face's :foreground changes to `#000000` in any
new frames created after the initial one (by calling `make-frame`),
because those frames' `background-color` and `foreground-color`
parameters default to "#000000" (possibly a bug with `disable-theme` too
eagerly defaulting them to black).
240493a replaces that with new, seemingly cleaner approach: setting
`frame-inherited-parameters`, which instructs `make-frame` to copy those
parameters from the last open frame, however, those parameters in the
initial daemon frame will be set to "unspecified-bg" or
"unspecified-fg" (see the docstring for `face-{back,fore}ground`), which
are invalid color strings. `make-frame` crashes tries to create a frame
with those color values, causing #8059.
Fix: #8059
Amend: 240493ae92
Amend: 9753bfb775
Those `face-*` calls sometimes returned nil, causing new frames spawned
from emacsclient to quietly crash sometimes. By instead relying on
`frame-inherited-parameters` we achieve the same but more stable result.
Amend: 9753bfb775
New frames created after the first get initialized with #000000 as their
{back,fore}ground-color parameters, for some reason, making text
unreadable in dark themes.
`(de?)activate-mark-hook` is triggered a little too often in too many
edge cases where the user isn't interactively selecting a region. One
annoying edge case has non-evil motions used on evil operators
activating but not deactivating the mark (e.g. #8047).
This leaves non-evil users without the nicety of hl-line auto-disabling
itself when the region is active, but I'll revisit that in v3.0, when
most of these package defaults are moved out to modules.
Fix: #8047
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.
This advice is intended to fake the death of buffers that are visible in
other windows, and prevent Emacs from switching to a non-real buffer
after it's killed/buried. It shouldn't even try to do any of this if
`kill-buffer-query-functions` fails, even if it is a fake death.
SPC is equivalent to y when y-or-n-p prompts you, which seems way too
easy to hit by accident, especially with our leader key being (or
involving) SPC by default.
BREAKING CHANGE: This removes git-gutter as an implementation for the
`:ui vc-gutter` module, leaving only the diff-hl implementation. There
are no longer any +git-gutter or +diff-hl flags for this module. Users
don't have to do anything to keep the vc gutter, unless they prefer
git-gutter for any reason (in which case they'll need to install and set
it up themselves).
This has been planned for some time, because of a roadmap goal for Doom
to lean into native/built-in functionality where it's equal or better
than the third party alternatives. diff-hl relies on the built-in vc.el
library instead of talking to git directly (thus expanding support to
whatever VCS's vc.el supports, and not git alone), which also means it
can take advantage of its caching and other user configuration for
vc.el. Overall, it is faster and lighter.
What I've also been waiting for was a stage-hunk command, similar to
git-gutter:stage-hunk, which arrived in dgutov/diff-hl@a0560551cd and
dgutov/diff-hl@133538973b, and have evolved since.
Ref: dgutov/diff-hl@a0560551cd
Ref: dgutov/diff-hl@133538973b
Ref: https://github.com/orgs/doomemacs/projects/5/views/1?pane=issue&itemId=58747789
The face and theme-face manipulation only needs to happen once per
frame, and the `set-fontset-font` calls only need to happen once per
session (or whenever the user calls `M-x doom/reload-fonts`). This
change ensures this and saves Emacs some work when initializing new
frames, as well as resolves `set-fontset-font` related segfaults in some
edge cases (#7803).
Fix: #7803
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
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.
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
317cea5 assumed Emacs 28, but Doom still tries to support 27.
Attempting to use the undefined emoji script on 27 results in an error.
Prior to 28, emoji are part of the symbol script, which the following
`set-fontset-font` call already handles.
Amend: 317cea5eef
Ref: #7448Fix: #7505
These are undocumented internal variables for basic platform-specific
fallbacks. Now that doom-symbol-font and doom-emoji-font exist, make
them constant.
No font supports all of Unicode or anywhere near it. It’s not even
really possible with current font formats. Therefore, rename
`doom-unicode-font` to `doom-symbol-font`. Only set it as a fallback for
characters in the `symbol` and `mathematical` scripts.
Nerd Fonts assign icons to code points in these Unicode Private Use
Areas. `doom-unicode-font` is now available again as a user-defined
fallback of last resort for non-PUA Unicode code points.
Ref: f12c615e4d (overview)
I'm using Emacs30 and on my version,
doom-apply-ansi-color-to-compilation-buffer-h does not colorize all the
escape sequences. Using ansi-color-compilation-filter instead fixes this
for me.
BREAKING CHANGE: This commit replaces all-the-icons with nerd-fonts. Any
all-the-icons-* function calls or variable references in your private
config will break and should be replaced with their nerd-icons-*
equivalent. That said, Doom will continue to install all-the-icons for
a while, so feel free to load it if you don't want to fully commit to
the change yet.
This change is happening because nerd-icon has wider support for GUI and
TUI Emacs; has a larger, more consistent selection of symbols; plus unicode
coverage.
Fix: #7368Close: #6675Close: #7364
Due to some packages and modules using this in some (non-GUI) builds of
Emacs. display-graphic-p isn't enough here, so rather than police all
the possible offenders, I've defined it to no-op in those cases,
instead.
Close: #6876
