`diff-hl-update-async` was enabled in f2696d7, causing a regression
where with-editor buffers wouldn't get cleaned up properly. This would
particularly affect Magit's COMMIT_EDITMSG buffers. To quote jds on
Discord:
It seems like after committing (with cc in the magit buffer), it
leaves COMMIT_EDITMSG around. The next time I try & commit, a single c
keypress immediately jumps to the old COMMIT_EDITMSG buffer, but it's
inactive - C-c C-c closes that buffer but makes no change to git.
I opt for advice instead of find-file or with-editor-mode hooks to
restore normal behavior should with-editor-mode be later disabled
without the death of its buffer (not relevant to magit, specifically,
but it might be to other consumers of with-editor, now or in the
future).
Ref: dgutov/diff-hl#213
Amend: f2696d7302
These advice were unnecessary when not only does diff-hl expose
variables to change them, but one of the overridden definitions is
identical to the function it's replacing.
Also includes some other minor refactors.
The NS build of Emacs (on MacOS) seems to struggle rendering our old
fringe bitmaps for diff-hl, leading to noticably slow-downs when
scrolling in buffers with diff-hl enabled. By pre-computing the pixel
height and width of the bitmap, rather than relying on passing `repeat`
to define-fringe-bitmap's ALIGN argument, this seems to spare it a chunk
of wasted cycles.
Ref: https://www.reddit.com/r/emacs/comments/1do1wgj/fringes_incredibly_slow_on_emacs_ns_with_macos/Fix: #7923
To be more consistent with other uses of the verb in the Emacs
ecosystem. Also done in preparation for a new +workspaces/delete command
for #7869.
Ref: #7869
This module has been deprecated for some time because it is too
trivially small, and it's always been unclear how hydra fits into Doom's
vision for its UI, but I intend to lean into either transient or Embark
in the future.
Folks seem to expect to *only* see the current project in the treemacs
pane when they open it. I sort of agree, so I've tweaked
+treemacs/toggle (on SPC o p) to use
`treemacs-add-and-display-current-project-exclusively` instead.
Fix: #7614
BREAKING CHANGE: This replaces volatile-highlights.el with goggles.el,
since the former is no longer maintained and the latter is a much
simpler implementation for the same functionality. No adjustments are
needed for end-users to adopt this change, unless they have
volatile-highlights-specific configuration.
Ref: https://github.com/orgs/doomemacs/projects/5/views/9?pane=issue&itemId=326184Close: #7810
Co-authored-by: Dev380 <Dev380@users.noreply.github.com>
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
`centaur-tabs-line-tab' reads `centaur-tabs-ace-jump-keys' without
length guards. If there are fewer entries than you have tabs, you'll see
an error (ema2159/centaur-tabs#231), and because the function is inlined
and monolithic, advising its behavior is non-trivial. This workaround
will mitigate it until it's dealt with upstream.
Ref: ema2159/centaur-tabs#231
At some point, either Emacs, persp-mode, or I fixed what caused #319,
which swallows the *Warnings* popup when the new main workspace is
created. Until I can determine what fixed it (so I can determine whether
the whole hack should go), I'll simply add this guard.
Ref: #319
`centaur-tabs-buffer-update-groups` walks every buffer to determine the
group it belongs to. This function can be called execessively (upwards
of 1,000 times per second in certain conditions), as it is called on
every redisplay (it is indirectly attached to `tab-line-format`). This
rate limits its calls to about 10 per second.
Close: #7792
Ref: ema2159/centaur-tabs#222
Due to upstream changes in ivy-rich, +workspace/switch-to throws a
`wrong-type-argument listp leaf` error. As I plan to phase out Ivy
support (and the Ivy module) in the long term, I'll simply remove
ivy (and ivy-rich) integration in the workspaces module, rather than
update it.
Fix: #7499Fix: #7173
dec058f fixed the load order between treemacs-nerd-icons and
lsp-treemacs, but lsp-treemacs still loads so late that folks will see a
theme-less Treemacs until they visit their first lsp-mode-enabled file.
This ensures that won't happen.
Amend: dec058fabb
Amend: #7519
Since we've remove all-the-icons, doom-themes-neotree-config will no
longer work properly, so I disable it for now (not a complete solution
though; we still need proper nerd-icons support for neotree).
Fix: #7634
Ref: #7664
BREAKING CHANGE: This deprecates the IS-(MAC|WINDOWS|LINUX|BSD) family
of global constants in favor of a native `featurep` check:
IS-MAC -> (featurep :system 'macos)
IS-WINDOWS -> (featurep :system 'windows)
IS-LINUX -> (featurep :system 'linux)
IS-BSD -> (featurep :system 'bsd)
The constants will stick around until the v3 release so folks can still
use it -- and there are still some modules that use it, but I'll phase
those uses out gradually.
Fix: #7479
As noted in #7556, the advice `+popup--evil-command-window-a` fails,
preventing the command window from being opened. This is because
`evil-command-window` has been rewritten extensively.
In particular, emacs-evil/evil@a09fdca0b3 made it use
`display-buffer` instead of `switch-to-buffer`, so that users could
customize how the window opens. Since this was the function of this
advice, it is obsolete and can be removed.
Fix: #7556
Ref: emacs-evil/evil@a09fdca0b3
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.
resetting font-ligatures means passing `nil` as the second argument
of `(set-font-ligatures!)`
Using `ligatures-ignored-major-modes` to cancel ligatures is too
brittle, because "resetting ligatures for `prog-mode`" would have bad
semantics with all its derived modes. The user probably just wants to
remove the default ligatures and then configure `foo-mode`, but pushing
`prog-mode` to `ignored-major-modes` might just disable ligatures across
all modes _derived from_ `prog-mode`.
This commit changes things in 2 ways:
- resetting ligatures now directly manipulates ligature.el internal
state (the `ligature-composition-table` alist)
- in order to work, Doom must maintain an extra invariant on that alist,
multi-modes keys (`'(foo-mode bar-mode)`), cannot be used, only single
modes.
That mostly means that users should _not_ use
`ligature-set-ligatures` themselves in private config, but instead
always rely on `set-font-ligatures!` which does splicing behind
curtains. Failing to do so would be mostly harmless though (it would
just make "resetting ligatures" only partially remove set ligatures).
Fix: #7433
