Toggles are great and all, but the trouble with the various toggles for line
numbers is that they force you to remember and think about the fact that there
are variant forms of line numbers. To beginners or forgetful people the various
combinations of behavior can be unintuitive here (e.g. toggling off relative
line numbers does nothing if you are actual in visual line numbers mode). Though
it doesn't fit exactly into the normal stuff we have for toggles, due to the
complexity of this situation I think it is good to just have a way to say "line
numbers be gone!"
Wasn't sure what keybinding to use, so used a double-tap mnemonic.
If this PR gets rejected, there are a couple minor fixes that should probably be
pulled out and submitted separately.
This reverts commit ec57b21a92.
A which-key change caused issues with this fix.
And the fix doesn't seem to be needed anymore.
The correct which-key entries appear without the fix.
problem
The evil-collection is loaded in the spacemacs-evil layer.
The spacemacs-evil layer isn't enabled by default
on the spacemacs-base distribution.
solution
Add buff-menu to the list: spacemacs-evil-collection-allowed-list
after the evil-collection has loaded.
problem:
pressing g shows the which-key entry:
r -> evil-mc
but it calls the expected commands:
revert-buffer (in dired)
magit-refresh
s -> evil-easymotion
but it calls the expected command:
magit-jump-to-staged
solution:
removing the gr and gs which-key entries,
shows the expected commands.
Moved the function definitions for:
spacemacs//trailing-whitespace
spacemacs//set-whitespace-style-for-diff
from: spacemacs-default/packages.el
to: spacemacs-default/funcs.el
* Group `line-number` funcs under SPC t n
* Better name: absolute-line-numbers
Keep the old symbols around for backwards compatibility
Co-authored-by: Rostislav Svoboda <Rostislav.Svoboda@gmail.com>
* [core] Fix evil keybindings when a link is selected in Custom-mode
This uses a separate keymap bound directly to the widget and circumvents the
existing evil keybindings.
This fixes the bug found by @duianto, which he posted
[here](https://github.com/syl20bnr/spacemacs/pull/13949#issuecomment-694685304).
* [core] Fix q and u to work everywhere in a Custom-mode buffer
The search next/previous commands are different
because of the `evil-search-module' values:
vim = evil-search
hybrid = isearch
- With the =vim= editing style in =normal= state:
- ~n~ =evil-ex-search-next=
- ~N~ =evil-ex-search-previous=
- With the =hybrid= editing style in =normal= state:
- ~n~ =evil-search-next=
- ~N~ =evil-search-previous=
As winner-mode was moved from init.el to dump-init.el winner-mode
was not longer properly started for non-dumped emacs sessions.
Having winner-mode auto activate at startup did fix the issue
for non-dumping users but in turn broke the dumping process.
I have now moved the necessary winner-mode init to
spacemacs/setup-startup-hook which is only called
in the non-dumping case. To allow customizations I activate
winner-mode prior to loading user-init this will allow users
to deactivate winner-mode in the dotfile and fix ediff themselves
if this is wished for.
Lazy loading of `winner-mode` breaks `ediff` and
`winner-undo`. As a hotfix I have deactivated
lazy loading for that package for now.
Just activating `winner-mode` after `winner-undo`
or `winner-redo` has been called does not solve
the issues described in #12582.
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.
Add aliases for commands that ido-mode remaps that we want to bind to
Spacemacs keys, and use these aliases in the Spacemacs key bindings so that
these bindings invoke the original commands rather than the ido commands.
See <https://github.com/syl20bnr/spacemacs/issues/10237#issuecomment-359861570>.
Emacs 26.1 will introduce a new native line numbers feature:
"display-line-numbers". It includes relative line numbers, is faster than
current linum-mode, and doesn't use the margin area (it has its own area). So
yeah, we want to use the new feature when possible.
No changes are required on the user side, except for Emacs 26 users are
recommended to remove nlinum layer from their configuration (if they have
enabled it).
With this change:
- Emacs 26:
- uses display-line-numbers by default.
- linum and linum-relative packages are excluded.
- Emacs 25:
- does NOT use display-line-numbers.
- continues to use linum and linum-relative.
- nlinum layer:
- can still be used as before in Emacs 25.
- is NOT recommended in Emacs 26, but can be used.
- when enabled, excludes display-line-numbers.
Also contains some bug fixes:
Fixes a bug where setting `dostpacemacs-line-numbers` to `t` or `relative`
enabled line numbers in every buffer, instead of only in buffers that derive
from prog-mode and text-mode.
Likewise fixes a bug where specifying `:enabled-for-modes nil` (or not
specifying `:enabled-for-modes` at all) in `dotspacemacs-line-numbers` settings
meant "enable in all modes" instead of "enable in modes derived from prog-mode
or text-mode".
Because of this change, also adds a way for users to enable line numbers
in *all* buffers.
Removes check for special buffer. All our current checks should be enough to
enable line numbers only where it makes sense. Disabling in all special buffers
is not necessary.
This idea is to have the spacemacs-base distribution only configure defaults for
built-in packages. Those buit-in packages are now configured in the new layer
spacemacs-defaults.
Additionally some other packages of spacemacs-base have been dispatched to
better suiting spacemacs layers.
Projectile has been moved to the new layer spacemacs-project
- Move the following packages to bootsrap distributio layer:
- exec-path-from-shell
- evil-evilified-state
- holy-mode
- hybrid-mode
- spacemacs-theme
- ace-window has been moved to spacemacs-navigation
- centered-buffer-mode has been moved to spacemacs-editing-visual
- pcre2el has been moved to spacemacs-editing
- evil-escape and evil-visualstar have been moved to spacemacs-evil
2018-03-04 20:54:54 -05:00
Renamed from layers/+distributions/spacemacs-base/packages.el (Browse further)
Lucius Hu
Lucius Hu
Daniel Nicolai
Keith Pinson
duianto
Maximilian Wolff
Evan Klitzke
Thanh Vuong
syl20bnr
Ivan Yonchovski
Bost
Keith Pinson
Brian Wignall
jcaw
Compro-Prasad
Miciah Masters
Kechao CAI
Codruț Constantin Gușoi
bmag
Bet4