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.
funcs.el is loaded after packages.el so `spacemacs//support-evilified-buffer-p` is undefined at this point.
moved it inside the `defun` block and it should work.
As described in #9169, when using the emacs editing style the comment inserted at the bottom of a git rebase shows the incorrect key bindings. This is apparently due to `evil-collection` (changing the `git-rebase-mode-hook`)[3ed92cadda/modes/magit/evil-collection-magit.el (L523-L524)].
We can fix the issue by only loading `evil-collection` if we're using an evil-style editing mode.
Closes#9169
Shelving and unshelving changelists are operations commonly used when
choosing Perforce as a VCS solution. Package consumed by the "perforce"
layer already provides "p4-shelve" and "p4-unshelve" commands that can
be exposed by the layer. Provide keybindings for these two commands as
well.
problem
In the `spacemacs-base` distribution.
When the `git-enable-magit-todos-plugin`
layer variable is enabled.
Then the following message appears on startup:
>An error occurred while pre-configuring magit-todos in layer git (error: (void-variable spacemacs-evil-collection-allowed-list))
cause
The `spacemacs-evil-collection-allowed-list` variable
is assigned in the `git` layer.
But it's defined in the `spacemacs-evil` layer.
The `spacemacs-evil` layer isn't used by default
in the `spacemacs-base` distribution.
solution
Check that the `spacemacs-evil` layer is used
before adding to the variable.
- Added `magit-todos` package, toggled by `git-enable-magit-todos-plugin`.
- Improved installation and loading of all magit-plugins:
- All magit plugins are toggled by their corresponding layer variables
PRE-INSTALLATION, instead of PRE-LOADING. That is, they are installed
only when the toggle is non nil.
- The `use-package` call is more specific now.
- Hooks goes to `:hook`.
- Removed `:defer` since it's implied by `:hook`, and it's actually not
doing anything.
- Improved the documentation.
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.
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.
problem:
key bindings that use the winum package,
don't work in the spacemacs-base distribution.
for example in the buffer transient state: SPC b .
{number}, C-{number} or M-{number}
shows messages like these:
Wrong type argument: commandp, winum-select-window-1
Symbol’s function definition is void: winum-get-window-by-number
cause:
the winum package is loaded in the spacemacs-navigation layer,
but the layer isn't used in the spacemacs-base distribution.
solution:
show the message:
This command requires the winum package,
winum is part of the spacemacs-navigation layer.
problem:
The Magit w (apply patches) arguments are not remembered between sessions.
cause:
Magit reads the transient files:
history.el, levels.el, and values.el
before Spacemacs has redirected them to the .cache directory.
solution:
Redirect the files before magit reads them.
This fixes g (magit-refresh), in the hybrid editing style when the variable:
hybrid-style-enable-evilified-state
is: nil
Thanks marienz for reporting the issue and for suggesting to check if the
editing style supports evil navigation.
https://github.com/syl20bnr/spacemacs/issues/14181#issuecomment-739251438
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.
Minified hint:
Chunks: n N p P RET Commits: b r f e q
Full hint:
Chunks Commits Other
[p/P] prev /same commit [b] adding lines [c] cycle style
[n/N] next /same commit [r] removing lines [Y] copy hash
[RET] show commit [f] last commit with lines [B] magit-blame
[e] echo [Q] quit TS
[q] quit blaming
