noctuid / evil-guide Goto Github PK

There is an evil-leader package, (which you can argue is not a good enough solution because it's not maintained anymore)

but it's quite easy to build your own leader-key functionality even without this package:

(defvar my-leader-map
  (make-sparse-keymap)
  "Keymap for 'leader key' shortcuts.")
(evil-define-key 'normal global-map "," my-leader-map)
(define-key my-leader-map " " 'whitespace-cleanup)
(define-key my-leader-map "b" 'list-buffers)

taken from: cofi/evil-leader#36

I happen to use evil-leader (definitely considering dropping it now that I realize it's been inactive, but until I find a showstopping bug, I'll keep it around) and find nothing wrong with it. It works with which-key (because it uses a keymap under the hood anyway), which yeah is kinda mundane since you should be aware of what your binds do, and has a neat interface for adding keys to the existing emacs session (M-x evil-leader/set-key[-for-mode])

I can write a pull req if you'd like.

Uh, wait a minute, you wrote general.el partly as a replacement for evil-leader. Why not at least mention the two?

In order to make SPC as my leader key globally, I used the method you provided,

(defvar my-intercept-mode-map (make-sparse-keymap)
  "High precedence keymap.")

(define-minor-mode my-intercept-mode
  "Global minor mode for higher precedence evil keybindings."
  :global t)

(my-intercept-mode)

(dolist (state '(normal visual insert))
  (evil-make-intercept-map
   ;; NOTE: This requires an evil version from 2018-03-20 or later
   (evil-get-auxiliary-keymap my-intercept-mode-map state t t)
   state))

(evil-define-key 'normal my-intercept-mode-map
  (kbd "SPC") my-cmd-map) ;; this is the only place I modified
 

Everything works well, the only exception is the * message * buffer shown when emacs startup.(at other times, * message * buffer works fine, and the startup scratch buffer works fine too)

I have checked the enable mode list by C-h m, my-intercept-mode has been activated correctly, but SPC doesn't bind to my-cmd-map but evil-forward-char.

If I press C-z twice to activate normal-mode again, then it can work properly, which is very strange.

Hi. I've read in the guide that:

In evil-integration.el, evil-make-overriding-map is used for dired and ibuffer. If you want to prevent evil-integration.el from being loaded, you can set evil-want-integration to nil before loading evil.

I have SPC as my prefix key in normal state. But having evil-want-integration set to nil, SPC still calls dired-next-line. It turns out that evil-integration doesn't make the overriding map, but evil-keybindings does. You have to set evil-want-keybinding to nil to prevent that.

I am not so familiar with evil, so I think it's best for you to add some information about this. But I would be happy to (try to) create a PR if you like that.

Warning (initialization): An error occurred while loading ‘/home/chenli/.emacs.d/init.el’:

Symbol's function definition is void: evil-make-overriding-map

To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file.  Start Emacs with
the ‘--debug-init’ option to view a complete error backtrace.

Here is my evil config:

(use-package evil
       :demand
       :ensure t
       :defer 0.1
       :init
       :config
       (evil-mode))
    (evil-make-overriding-map dired-mode-map 'normal)

awesome text, thanks a lot for putting this online, even if you consider it a draft.

since you mention both the repeat system and hydras... any chance you know how to get those to play well together? e.g. i have , c (comma followed by c) bound to a hydra (i use comma as my "leader" key), but pressing . to repeat the hydra command after use does not work.

i tried this:

(evil-declare-repeat 'my-hydra/body)

... which unfortunately does not work.

Checked with the Info documentation for 'evil' with the above number. Under the section on "Keymaps" there is a section called "Leader Keys". This seems to say that the evil supports vim 'leader' keys. On the other hand the 'evil-guide' says there is no exact analogue of vim's 'leader' keys.

Seems to be some discrepancy. Does one need to install 'evil-leader' or not?

Hello,

A problem while searching in EVIL using / (with isearch) and pressing ESC is that the point doesn't go back to where the search started but pressing Ctrl-g instead of ESC does send you back. It looks like ESC is mapped to isearch-cancel and Ctrl-g is mapped to isearch-abort.

I have tried with many variations from your guide explanations to map ESC to isearch-abort instead of isearch-cancel with no success.

How can I make ESC send isearch-abort during a search? I know about the evil-search module which does the 'correct' thing but lacks the features of isearch which I prefer.

The guide says the following:

In emacs state, C-z and ESC are bound to switch to the previous state.

This does not appear to be the case -- ESC acts like normal Meta in Emacs state by default.

Also, the suggestion on how to bind ESC in emacs-state only works in the GUI, but not in the terminal:

(define-key evil-emacs-state-map [escape] 'evil-normal-state)

Unfortunately, binding (kbd "ESC") overwrites Meta, and thus important keys like M-x, in the terminal. I would like a way for ESC in emacs-state to behave the same as in insert-state, but it's not clear to me if it's possible.

I'm using your tip for relative line numbers from here, but it bothers me that the number for the current line does not scale with the other numbers when I use "text-scale-adjust." This creates an annoying mismatch on the current line. Here's how it looks in action: https://gfycat.com/WeepyMarriedInganue I think the line numbers are to blame because this doesn't happen without them.

Look how small the current line number becomes (it's "nil" in my case, so it's always zero)

It's also small if I use your function unaltered, with actual current line numbers.

I think making the current line number scale up could solve the issue, but I don't know how to do it.

Great guide already, and hopefully will be even better
Spacemacs can benefit from some if not all parts of it
So, if you are in favor - please add compatible license

And given chance, I want to say - you are keytastical

evil-want-Y-yank-to-eol is not equivalent to y$. The former yanks from the beginning of the line to the end of the line whereas the latter yanks from the current cursor to the end of the line. How can I replicate this behavior on emacs?

As you mentioned that you don't use evil-magit in the article, what's your solution to use evil bindings for magit? (or even you don't use magit?).

I find that evil-collection doesn't provide bindings for magit(it just fix some trivial problem for evil-magit I think). However, evil-magit's bindings have some conflict with the idea "Make Evil Normal State the Initial State Always". Most of the time they bind key under normal state, but they are some "evil-magit-untouched-mode" , where they will not change the state of buffer to normal-state but use the default one (which is emacs-state for magit according to the default value of evil-emacs-state-modes).

This bothers me, since I do what you suggest to make all modes start in normal-state always(I agree this might be the simplest way to reduce the complexity of keybindings), but there will be some awkward situation when using evil-magit.

For example:

1. M-x magit-status
2. press s to stage some files
3. press c to commit (than emacs will popup a buffer called magit-commit-popup, which is categorized as evil-magit-untouched-mode under evil-magit, so it will stay as what it originally should be.
4. press c again to write commit message, (this steps crash)

Since magit-commit-popup use the keybindings of emacs-state, if we force it to start at normal-state, the second c will run evil-change but not magit-commit-create. This is really annoying. Of course we can push modes defined in evil-magit-untouched-mode back to emacs-state and all this works, but I prefer to find other more clean solution. I'm all ear to your solution to magit.