cause:
The spacemacs|add-toggle expression,
ended up in the combined setq above.
additional changes:
Separated the combined setqs, to make it
easier see where each assignment starts.
Wrapped the lines at 80 chars to reduce
the need to scroll horizontally.
The newly added bindings had side effects for
magit. This was caused by which-keys replacement
working on bindings which are identical between
various modes.
To fix this I have changed the api to use the newly
added keymap based replacements which avoid these
issues.
As a side effect they are a ton faster as which
key does not have to compare all available bindings
everytime it opens its help window.
I have also fixed some more missing which-key
description in magit status buffer.
Resolves#13948
problem:
The p key tries to paste in the read-only magit buffer,
instead of calling magit-push.
After toggling text-mode on and off (C-t or \),
because evil-mc-mode becomes enabled when text-mode is enabled.
Following the advice from duianto #13100 we are
setting completion-styles for helm-M-x to include
the emacs version specific fuzzy strategy as last
resort.
Before no fuzzy matching occured within command
searches.
The warning:
nlinum layer is deprecated for Emacs 26.1 and above
wasn't shown until SPC h SPC was pressed.
Because the variable: configuration-layer--used-layers
wasn't populated before the warning check occurred in
nlinum/packages.el.
The solution (suggested by syl20bnr) was to move the
check to a new file: nlinum/config.el.
Removed the following key bindings from the multiple-cursors layer:
grI evil-mc-make-cursor-in-visual-selection-beg
grA evil-mc-make-cursor-in-visual-selection-end
because they have been added upstream in the evil-mc package.
Changed the changelog.develop entry from saying that they were
added to the layer, to say that they were documented in the layer.
Added evil-mc make cursors from selection key bindings:
grI calls evil-mc-make-cursor-in-visual-selection-beg
grA calls evil-mc-make-cursor-in-visual-selection-end
Emacs 26 added built-in support for line numbers, relative line numbers, and
visual line numbers. Spacemacs supports only absolute and relative, but there is
no way to access the visual mode. It's hard to get around this, since Spacemacs
abstracts line numbers to a reasonably high degree.
Arguably, `visual` is much more useful than `relative` as a display type. Visual
line numbers are like relative line numbers, but only lines that are actually
showing are counted. This means:
1. Hidden lines are not counted. If a large amount of text is folded, the line
numbers won't jump from "10" to "546". This is particularly useful in
buffers like `magit-status`, where a large amount of information is folded
by default.
2. Lines that are wrapped are counted as multiple lines, since they're being
displayed as multiple lines in the editor. Each visual line will be
numbered - unlike `relative`, where the entire thing is numbered... Once.
With standard relative line numbers, you can't actually navigate using the line
numbers in the sidebar as soon as folded or wrapped lines are introduced. Since
this is one of the main use cases for relative line numbers, this is a big
problem.
Visual mode fixes that problem. Every line that's being displayed is labelled.
Numbers always correspond to the actual number of lines you'd need to navigate
to reach that line.
This commit extends Spacemacs' line number interface to provide visual line
number support.
Commit gabesoft/evil-mc@041b904475 changed
the default key bind of `g r u` to a different (new) function. The old
behaviour is now available at `g r q`.
ietf layer declared a wrong use-package
declaration, which tried to load ietf-docs
instead of the locally installed irfc package
causing irfc-mode to fail loading.
duianto
Maximilian Wolff
emacspace
Kevin
Robert O'Connor
Tim Jäger
wangtianshu
kimr
Seong Yong-ju
deb0ch
jcaw
bb2020
Anton-Latukha
JAremko
Bet4
Henrique Jung
Christian E. Hopps
duianto
Aaron Renner
Codruț Constantin Gușoi
Boris Buliga