Wherever an interactive motion command (that good-scroll has advised) is
used programmatically.
This should be addressed upstream. Either by adding
boundary/called-interactively guards to
`good-scroll--point-at-top-fix-a`, or by avoiding interactive motion
commands in ledger-mode.
Fix: #8376
Commit 0893edefae removed magit-todos and
the "SPC p t" keybinding. The documentation of hl-todo does not reflect
this change.
This commit removes said keybinding from hl-todos documentation.
When Emacs is started as a daemon and no frames exist, `emacsclient -c`
should simply switch to the main workspace. However, before
`+workspaces-associate-frame-fn` is called, the new frame is already
added to the frame list, which causes `persp-frame-list-without-daemon`
to always return a non-empty list. A new workspace will be created
instead of switching to the main one.
A "workspace already exists" error is thrown if trying to switch to
project workspace that already exists. This changes it to switch to the
workspace instead.
Fix: #8368
Restoring indirect buffers indiscriminately isn't so simple, and can
come with unserializable data that Emacs will throw errors on while
restoring a saved workspace.
Revert: 5f04be599fFix: #6043
Due to a race condition in some contexts, hooks that adjusted window
fringes or margins weren't targeting the windows (usually popups) they
were supposed to, often affecting the last selected window instead. This
could cause the fringes (or margins) to resize or outright vanish
unexpectedly in the wrong windows (e.g. after opening or killing a vterm
or eshell popup).
Fix: #8346
Adds optional scroll interpolation/animation in #8335 via the
good-scroll package. Command support is light right now, but I plan to
expand on it later, and I welcome PRs to do so in the meantime.
Ref: #8335
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.
Normally, this would be too small to warrant its own module, but smooth
scrolling is one of those things that can tip large swaths of
fence-sitting beginners into Emacs' camp. I can't help but imagine how
many people get their impression that Emacs is "laggy" or "slow" solely
from the way it scrolls.
Don't get me wrong, there *are* good reasons to call Emacs slow, but
startup and scrolling speed are not it, yet they are easily overblown
because it's the first thing you see. I might even consider enabling
this by default, but I'll make that decision later.
Fix: #8335
If you used `projectile-switch-project`, the workspaces module would
open a new workspace named after the project, but if a workspace named
after that project already exists, it is hijacked (e.g. two projects in
'some-project/src' and 'another-project/src' would get the same name:
"src"). This commit uniquifies their names so this doesn't happen, and
also embeds a +workspace-project persp parameter in the workspace so
that they can be disamiguated later (this association is lost if you
rename the workspace manually, however).
Fix: #7637
This command would formerly raise the focused window into a regular
window, erroring out if that window isn't a popup. Now, if the focused
window isn't a popup, any (single) visible popup in the current frame
will be targeted, and if multiple popups are visible, you'll be prompted
to select one.
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.
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
