This is due to :align-to factoring in the margins into its alignment,
which is ever changing in the dashboard buffer (or anywhere
visual-fill-column is active).
Even though `mode-line-right-align-edge` was introduced in Emacs 30,
doom-modeline backports so, so its users should benefit from this as
well.
Close: #8114Fix: #7466Fix: seagle0128/doom-modeline#668Fix: seagle0128/doom-modeline#672
Co-authored-by: unipro <unipro@users.noreply.github.com>
These optional dotfiles indicate the root of a module or module
group (:lang), and will later contain module metadata. They will also
serve as an alternative to packages.el and doctor.el, and will aide the
parts of the v3.0 module API concerned with resolving the current module
from a path (`doom-module-from-path`), which currently rely too heavily
on parsing path strings.
For now, however, they're simply placeholders.
Otherwise, `prettify-symbols-alist` will be set to a list whose first
element is the mode name, a symbol. That makes `prettify-symbols-alist`
an invalid alist, so when `prettify-symbols-mode` is enabled, there's a
type error in `prettify-symbols--make-keywords`.
Amend: c07f359d64
With +extra enabled, this module would activate `prettify-symbols-mode`
in any buffer where `prettify-symbols-alist` is non-nil, whether or not
`+ligatures-extra-alist` has an entry for the current major mode (or a
parent thereof). This behavior is poor UX, since the user may be
expecting that a empty entry for some `X-mode` in
`+ligatures-extra-alist` should mean *no` prettify-symbols-mode` at all
in `X-mode`.
With this, `+ligatures-extra-alist` is now the authority. An empty entry
for `X-mode` will result in `prettify-symbols-mode` *not* being
activated there. If that entry *isn't* empty, it will be combined only
with the global default value of `prettify-symbols-alist`, not any
pre-existing buffer-local value, to make the end result deterministic,
because some modes have their own defaults for it (like
`lisp-prettify-symbols-alist`, `js--prettify-symbols-alist`, and
`rust-prettify-symbols-alist`).
Fix: #7440
BREAKING CHANGE: This removes the irony and rtags packages so we can
lean on LSP servers like clangd and ccls fully, which provide the same
features with much more consistency.
Close: #8049
In e0a926d, I defaulted to not using bitmaps for indent-guides, but
after some more research, I realize this slowness is more prominent on
MacOS, older PGTK builds, and (possibly) Windows, so I've opted to
re-enable bitmaps by default, unless you're on one of those
systems (except Windows; still testing that).
This change also makes the guide bars more subtle, since the default is
too distracting and colorful.
Ref: #8052
Ref: e0a926dc1e
Changing workspace is big motion so we should blink the cursor.
We can not use `+nav-flash-blink-cursor-maybe-h` as the point
is not yet in the correct buffer when the hook is triggered.
The bitmap method is slower and not that different, visually, from the
character method.
Fix: #8052
Co-authored-by: nightkr <nightkr@users.noreply.github.com>
Dirvish uses the fringe for its vc-state diff, which isn't available in
TTY Emacs, so we still need `diff-hl-dired-mode` there.
Revert: a8ed6c9f7d
Ref: #6760
Otherwise, each time `+workspace-save` is called, all prior saved
workspaces would be deleted from `+workspaces-data-file` before
inserting the new one.
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
