Fixes: vim layer key binding of "J" in dired mode #14614https://github.com/syl20bnr/spacemacs/issues/14614
problem
The evil collection binds "J" to `dired-go-to-file`
It overrides the Spacemacs `helm` and `ivy` equivalent commands.
`spacemacs/helm-find-files' has fuzzy matching and other features
`spacemacs/counsel-find-file' has more `M-o' actions
And the `ivy` layer uses the `spacemacs/helm-find-files` command.
solution
Move the Spacemacs definitions of "J",
after the evil collection dired keys have been setup
from: `spacemacs-bootstrap/packages.el`
to: `spacemacs-evil/init-evil-collection`
And use `spacemacs/counsel-find-file` in the `ivy` layer.
This restores the previous Spacemacs
Info-mode and help-mode buffer bindings.
for example:
before:
The square bracket keys are prefixes for one key:
"[u" 'evil-collection-unimpaired-url-encode
"]u" 'evil-collection-unimpaired-url-decode
after:
] ;; Info-forward-node
[ ;; Info-backward-node
] ;; help-go-forward
[ ;; help-go-back
Fixes: Evil keybindings for navigation no longer behave as expected in Info buffers #14375
It is impossible to ignore `evil-collection` anymore. `evil-magit` has been
deprecated recently and moved to `evil-collection`.
It will save time and effort for both Spacemacs and Evil to share and contribute
to `evil-collection` imo.
However I strongly prefer Spacemacs binding scheme over evil-collection's one.
We should only pick what we need from `evil-collection`.
This PR add mechanism to embrace `evil-collection` and apply it to shell layer (`vterm`)
and git layer.
Thanks sdwolfz for the suggestion to add underscore to the transient states,
then the shift key doesn't have to be released if it was held down to press `+`.
Added key bindings:
Evil numbers:
`SPC n _` decrease number under point
in the transient state:
`j` decrease number under point
`k` increase number under point
`SPC T T _` decrease transparency
`SPC z x _` scale down font
`SPC z f _` zoom out frame
Update documentation:
Zoom frame:
`q` quit transient state
Evil numbers:
`SPC n =` increase number under point
`SPC n _` decrease number under point
`0..9` add a number prefix argument
`q` quit transient state
Fixed a typo and made a small rewrite of the tip about using a prefix argument.
Added keys to transient states:
Font scaling:
Added `_` scale down
Reordered `k` assignment to match the order in the transient state
Frame transparency:
Added `_` decrease
Reordered `k` assignment to match the order in the transient state
Evil numbers:
Added `k` increase
Added `_` and `j` decrease
Zoom frame:
Added `_` zoom frame out
Reordered `k` assignment to match the order in the transient state
Which-key entries for Evil numbers `SPC n`:
Group together keys that call the same command:
From: + and =
To: +,=
From: - and _
To: -,_
`SPC h T e` for `emacs-tutorial` (aliased from `help-with-tutorial` for a more
descriptive name)
`SPC h T v` for `evil-tutor-start`
Added a wikipedia link to the `vi` article, where the origins of modal editing
is discussed.
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.
Only using visual state as entry point for evil-surround doesn't guarantee
surround is available for evil-yank and evil-delete. Fixed by also using
operator state.
Fixes#11019 and #11021
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
This reverts commit 29c78ce841 and all other fixes
that have been made afterwards.
The motivation is that use-package is seen by many as a replacement for
`require`. Is use-package always defer the loading of packages then is breaks
this use case, this does not respect POLA so even if it was making Spacemacs
loading faster (up to 3s faster on some startup on my machine) we just cannot
use it, it would be irresponsible. Spacemacs should be easy to use, loading
performance will come with time but it is not a priority.
Delete layer evil-cleverparens and move the package to spacemacs-evil layer.
The feature is called "Safe structurral editing" for lisp dialects. Support for
it is added via pre-init functions in each of the concerned layer and proper
documentation is added to their README.org files.
This also removes the recently added package evil-smartparens. The goal is
to choose the best package for evil safe structural editing. For now we use
evil-cleverparens as we supported it first, if evil-smartparens is shown to be
a better package we will be able to switch to it.
