This was an elusive bug caused by two upstream behaviors:
1. `kill-buffer` will silently refuse to kill a buffer if there is a
thread associated with it.
2. `global-diff-hl-mode` activates `diff-hl-mode` in *most* buffers,
even invisible ones. This calls `diff-hl-update` each time
it does. This isn't a problem *unless* you have `diff-hl-update-async`
enabled, because it creates a thread every time `diff-hl-update` is
called. That means for every buffer -- real or transient -- you have
a new thread queued.
And this caused two main issues:
1. Temporary buffers are often opened and closed very rapidly (often
faster than the thread can complete), so they weren't getting cleaned
up. I hope you weren't too attached to your memory, because you'll
have a lot of buried buffers to feed before long!
2. In cases where `diff-hl-update` simply takes a long time, multiple
calls to it would queue more threads. When Emacs eventually yields
the CPU to them, you'll get random,
impossible-to-predict-or-track-down freezes. Joy!
This may very well be enough reason to disable `diff-hl-update-async` by
default, but I didn't want to give up on it *just* yet, despite how
inelegant this solution is...
Fix: #7954Fix: #7991
Adapts to changes made upstream to Org's window management logic (e.g.
Org dropped `org-switch-to-buffer-other-window` for
`switch-to-buffer-other-window`, and org-journal renamed one of its
helper functions).
Doom removes the "none" workspace from persp-mode's default list of
perspectives, because it is a special case that doesn't behave
identically to other persps in the list, making it a pain to deal with.
This worked fine up until a change to `persp-update-names-cache` (in
Bad-ptr/persp-mode.el@0d6cacc) made it re-insert this "none" workspace
into `persp-names-cache` whenever it is called, undoing our hack; this
commit adapts to that change.
Ref: Bad-ptr/persp-mode.el@0d6caccab3
Ref: Bad-ptr/persp-mode.el@b2e68f97cbFix: #7986
Amend: 7f3412e317
For deleting saved workspaces (saved with `+workspace/save` or
`+workspace-save`).
Also binds `SPC TAB D` (for evil users) and `C-c w K` (for non-evil
users) to it.
Fix: #4399Close: #7869
Co-authored-by: sriramsk1999 <sriramsk1999@users.noreply.github.com>
This advice was suppressing ws-butler's modification hooks, which had a
nasty side-effect of modifying org buffers without letting its
org-element cache know that it's stale, which resulted in errors like
this, followed by a backtrace:
Warning (org-element): org-element--cache: Unregistered buffer modifications detected (175 != 176). Resetting.
If this warning appears regularly, please report the warning text to Org mode mailing list (M-x org-submit-bug-report).
The advice isn't needed anymore, anyhow.
Our former approach would enable diff-hl unconditionally. This way, the
`diff-hl-global-modes` variable is respected.
Ref: https://discourse.doomemacs.org/t/4710/2
`treemacs-add-and-display-current-project-exclusively' seems to confuse
some people and please others when it is used in $HOME. To reduce
confusion, SPC o p will now resume from the last session if
default-directory isn't a valid project OR if it's $HOME. It will also
emit a warning informing them of that.
Fix: #7948
Amend: f9dfb7e92a
`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
