August 2011 - implementations-list - lists.ourproject.org

Define keys more easily?
by Michael Markert 20 Aug '11

20 Aug '11

Hi, my key definitions come in packs, so instead of #+begin_src emacs-lisp (eval-after-load 'speedbar '(progn (evil-make-overriding-map speedbar-key-map) (evil-make-overriding-map speedbar-file-key-map) (evil-make-overriding-map speedbar-buffers-key-map) (evil-define-key 'motion speedbar-key-map "h" 'backward-char) (evil-define-key 'motion speedbar-key-map "j" 'speedbar-next) (evil-define-key 'motion speedbar-key-map "k" 'speedbar-prev) (evil-define-key 'motion speedbar-key-map "l" 'forward-char) (evil-define-key 'motion speedbar-key-map "i" 'speedbar-item-info) (evil-define-key 'motion speedbar-key-map "r" 'speedbar-refresh) (evil-define-key 'motion speedbar-key-map "u" 'speedbar-up-directory) (evil-define-key 'motion speedbar-key-map "o" 'speedbar-toggle-line-expansion) (evil-define-key 'motion speedbar-key-map (kbd "RET") 'speedbar-edit-line))) #+end_src emacs-lisp I like it #+begin_src emacs-lisp (eval-after-load 'speedbar '(progn (evil-make-overriding-map speedbar-key-map) (evil-make-overriding-map speedbar-file-key-map) (evil-make-overriding-map speedbar-buffers-key-map) (evil-define-keys 'motion speedbar-key-map "h" 'backward-char "j" 'speedbar-next "k" 'speedbar-prev "l" 'forward-char "i" 'speedbar-item-info "r" 'speedbar-refresh "u" 'speedbar-up-directory "o" 'speedbar-toggle-line-expansion (kbd "RET") 'speedbar-edit-line))) #+end_src emacs-lisp Easier to type and easier to read and understand, right? Is it worth to include it? And if, is it worth to keep the single key functions? The code is in my keys branch[1]. I did not open a merge request because I don't want it included half finished (the rest of the key functions). Michael Footnotes: [1] https://gitorious.org/~cofi/evil/cofis-evil/commits/keys

2 2

One more evil user: ^W and viper-in-more-modes
by Christoph LANGE 18 Aug '11

18 Aug '11

Hi Frank, hi Vegard, here is one more user who switched from vimpulse to evil. It's great to see that there has been so much progress recently, and that there is even a lot of functionality that had not existed before. (Well, at least vim-style macros with q and @ did not exist in vimpulse – maybe they did in vim-mode – and I was impressed to see them supported.) You can be sure that I will report any bugs as soon as I encounter them. For now, there are two things I'm missing: * I would like ^W in insert mode to behave as in vi. For now I fixed that as follows: (define-key evil-insert-state-map "\C-w" 'backward-kill-word) Maybe you could make it customizable as something like "Evil Want C W Delete". (Note that the term "delete" is rather vim than Emacs style. I took it from vim's help, which documents ^W as "delete word before the cursor".) * I am looking forward to a port of viper-in-more-modes, which I am currently using in emacs-lisp-mode and LaTeX-mode. Cheers, Christoph -- Christoph Lange, http://de.wikipedia.org/wiki/Benutzer:Langec, Skype duke4701

2 5

Visual operation in Info mode
by York Zhao 18 Aug '11

18 Aug '11

Hi, "motion state" is handy however when a mode is in motion state I lose the ability to select text which was the reason of my following code: (eval-after-load 'info '(progn (evil-define-key 'motion Info-mode-map "v" 'evil-visual-char))) But then the info mode would end up in normal state which is not what I wanted, is there any way to solve this? Thanks, York

4 10

The last ex command not showing up automatically
by York Zhao 17 Aug '11

17 Aug '11

Hi, So far the inconvenience thing I have noticed about ex command in Evil compared with that in Vimpulse is that when I typed ":" the last command was not showing up automatcally. This is not convenient because I sometimes use ":w RET" instead of "C-x C-s" to save the buffer. If the "w" was already there I could have typed ": RET" to save the buffer which saved one key stroke. York

2 2

Evil: compatibility patch for bs mode
by Tom Short 16 Aug '11

16 Aug '11

See enclosed for a small patch to add compatibility code for the bs mode. If adds hjkl to the normal emacs keys in a fashion similar to the dired support. Hopefully, this is the right forum and a suitable patch format. If not, let me know, and I'll try again. I couldn't figure out how to do a gitorious merge request. - ts

1 0

evil inside
by Timothy Harper 14 Aug '11

14 Aug '11

Just wanted to post that I switched out vimpulse for evil, and I am digging it! Great work guys! It feels more responsive, and less buggy. I've started to extend evil to implement surround. So far I have surround region implemented, that was easy. evil-define-key works brilliantly. Change surround / delete surround is going to be a little more tricky though. Previously, my approach was to implement custom text objects that were flagged as surrounding text objects. Then I implemented vimpulse-delete-surround-or-delete, vimpulse-change-surround-or-change, bound then to 'd' and 'c' respectively, and prompted for a text object. If the returned text object was flagged as a surround text object, I acted accordingly, otherwise forwarded on to vimpulse-delete / vimpulse-change. I think a better approach, this time, would be to implement evil-change-maybe-surround. It would prompt for the next keystroke. If 's', then prompt for a text object and perform the operation. Otherwise, stick the key back into unread-command-events and forward to evil-change. Does a better extension mechanism exist, or is that approach a good one in your eyes (Vegard?) Thanks so much for bringing evil to my emacs! :) Tim

5 8

"vi>" woks like "va>" while "va>" doesn't work
by York Zhao 12 Aug '11

12 Aug '11

Hi, I have this text: (define-key evil-normal-state-map (kbd "<backspace>") 'scroll-down) I noticed that in text mode the result of the operation "vi>" and "va>" gets swapped. While in Lisp mode "vi>" still gets the surrounding "<>" selected as it would with "va>' and "va>" selected the entire line except the most outside "()". I have tested it in "make emacs" with the same result. York

2 3

Rebinded key becomes un-changeable
by York Zhao 12 Aug '11

12 Aug '11

Hi, I have this code to inherite most of the ibuffer key bindings while still keep the "j" and "k" bindings. (eval-after-load 'ibuffer '(progn ;; use the standard ibuffer bindings as a base (set-keymap-parent (evil-get-auxiliary-keymap ibuffer-mode-map 'normal t) (assq-delete-all 'menu-bar (copy-keymap ibuffer-mode-map))) (evil-define-key 'normal ibuffer-mode-map "j" 'ibuffer-forward-line) (evil-define-key 'normal ibuffer-mode-map "k" 'ibuffer-backward-line) (evil-define-key 'normal ibuffer-mode-map "J" 'ibuffer-jump-to-buffer) ; "j" )) This works fine however if I rebind the <backspace> before the previous code like this: (define-key evil-normal-state-map (kbd "<backspace>") 'scroll-down) The <backspace> key would then "fixed" to my binding (scroll-down) instead of the ibuffer binding. Is there any "better" way of rebinding evil keys? Or, is it possible for Evil to handle this situation? Thanks, York

2 4

Modify repeat keys?
by Michael Markert 11 Aug '11

11 Aug '11

Hi, I'm using this function to exit insert state with jk (use `(define-key evil-insert-state-map (cofi/maybe-exit ?j ?k))')

3 8

Fails to byte compile in latest commit
by York Zhao 11 Aug '11

11 Aug '11

Hi, I just pulled the latest version of evil and noticed some errors and lots of warnings when I did "make" to byte compile. I then checked the time stamp of the .elc files and noticed that some of the some files haven't been byte compiled. Thanks, York

3 7