June 2013 - implementations-list - lists.ourproject.org

<backspace> not bound properly in haskell-mode
by Keshav Kini 25 Jul '14

25 Jul '14

When I have a .hs file open in a buffer (i.e. with haskell-mode activated), it seems that typing <backspace> in <N> state actually deletes characters. Investigating a bit, I see that in other modes - such as message-mode, in which I'm typing this email - doing describe-key on <backspace> yields the following: DEL (translated from <backspace>) runs the command evil-backward-char, which is an interactive compiled Lisp function in `evil-commands.el'. In haskell-mode, however, I get: <backspace> runs the command haskell-indentation-delete-backward-char, which is an interactive compiled Lisp function in `haskell-indentation.el'. The difference I notice is that in the first, we have "DEL (translated from <backspace>)", but in the second, just "<backspace>". From this I gather that evil-mode probably traps the key DEL, but not the key <backspace>. Should evil-mode perhaps trap <backspace> directly as well as DEL? Or is this a bug in haskell-mode, i.e. should haskell-mode be trapping DEL instead of <backspace>? -Keshav

2 2

A couple of questions
by Keshav Kini 13 Sep '13

13 Sep '13

Hello, First of all, thank you very much for your great work on evil! I'm really pleasantly surprised at how active your development is :) I'm a vim user who is trying to learn emacs without losing the handy modal editing of vim (as I imagine many others on this list are), and evil seems to be exactly what I need. I have a couple of questions. First, I am wondering if evil-want-C-u-scroll is broken. I have set it to t using M-x customize-group evil-mode, which causes (custom-set-variables '(evil-want-C-u-scroll t)) to appear in my ~/.emacs , but I don't see any difference in the behavior of evil. Is there something else I need to do in order to make C-u call evil-scroll-up (as C-h k C-d tells me that C-d is bound to evil-scroll-down)? Second, I am wondering about the behavior of :q . It seems to me that it behaves more like :qa does in vim. According to vim documentation, :q[uit] should "Quit the current window. Quit Vim if this is the last window.". So I guess it should be similar to kill-buffer in emacs, no? Thanks again! -Keshav

6 10

strange behaviour with f, r and t in evil mode: next key is taken as being a command in normal mode
by Eric S Fraga 06 Jul '13

06 Jul '13

Hello, I just upgraded both emacs and evil. The latest commit for evil is ,---- | commit 9d0d51ffc4281b2e716618fcdbe52414a81aa7b6 | Author: Michael Markert <markert.michael(a)googlemail.com> | Date: Fri Jun 7 11:22:24 2013 +0200 | | Move ace-jump-mode integration out of `eval-after-load`. `---- and emacs is the snapshot from 11 June. Now, when in normal state, commands like f (evil-find-char), t (evil-find-char-to) and r (evil-replace) no longer work because the next keystroke is read as if in normal mode (e.g. typing "f x" causes the character under the cursor to be deleted). I can revert evil to an earlier state, of course. The only commit I see from the previous couple of weeks (since the last time I pulled from the git repository) that could have something to do with this (but only because I don't actually understand the commit message ;-) appears to be: ,---- | commit bcf0bac71c984ea45dc94f283e281f4ffbc5b4a1 | Author: Frank Fischer <frank.fischer(a)mathematik.tu-chemnitz.de> | Date: Fri May 24 22:01:11 2013 +0200 | | Disable narrowing in char arguments in operator state (fix #294) | | When éa motion is read in operator state, the buffer is narrowed to | the current field so that the operation is always restricted to that | field. If a character argument is read then this restriction is | visible. This fix disables the restriction temporarily if an argument | with the <C> interactive code is used, which is the case for f,F,t and | T motions. `---- The problem arises with emacs -Q and only evil loaded so the problem is not caused by any customisation I have made, as far as I can tell. Thanks, eric -- : Eric S Fraga, GnuPG: 0xFFFCF67D : in Emacs 24.3.50.1 + Ma Gnus v0.8 + evil 1.0.5 : BBDB version 3.02 ($Date: 2013/05/15 13:17:58 $)

6 9

Evil: Yank/Paste with System Clipboard and Evil in New Buffers
by Haroogan 27 Jun '13

27 Jun '13

Hello, Question #1: (defun haroogan/evil-paste-from-clipboard () "Paste text from system clipboard." (interactive) (evil-paste-from-register ?+)) (evil-define-operator haroogan/evil-yank-to-clipboard (beg end type yank-handler) "Yank text to system clipboard." :move-point nil :repeat nil (interactive "<x><y>") (evil-yank beg end type ?+ yank-handler)) Paste works as intended. Yank works partly: * after yanking I can paste this text into other applications; * but I cannot paste it into the Emacs itself, i.e. by using|haroogan/evil-paste-from-clipboard|- it says that the|kill-ring|is empty; how come? * furthermore, bell rings when I'm yanking with this function - like if it was an error - that's very strange too. For the reference, in my|.vimrc|I have the following: " Cut to the system clipboard. nnoremap <C-x> "+x vnoremap <C-x> "+x cnoremap<C-x> "+x " Yank to the system clipboard. nnoremap <C-y> "+y vnoremap <C-y> "+y cnoremap<C-y> "+y " Paste from the system clipboard. nnoremap <C-p> "+p vnoremap <C-p> "+p cnoremap<C-p> "+p What's the best way to replicate this with Evil? Question #2: Evil provides the following function: (evil-define-command evil-window-new (count file) "Splits the current window horizontally and opens a new buffer or edits a certain FILE." :repeat nil (interactive "P<f>") (split-window (selected-window) count) (if file (evil-edit file) (let ((buffer (generate-new-buffer "*new*"))) (set-window-buffer (selected-window) buffer) (with-current-buffer buffer (evil-normal-state))))) In my opinion the last line reveals a huge flaw. First of all, recently I've been writing a tiling window manager for Emacs. Of course when I create new windows there, I create buffers as well with the same generate-new-buffer function. And of course as suggested by the evil-window-new function presented above, one has to call (with-current-buffer buffer (evil-normal-state)) so that Evil does not break here and works properly in this newly created buffer. That's incredibly annoying for 2 reasons. First, now, for instance, my tiling window manager has to depend on the Evil package just to make this little hack for those who wish to use Evil with my tiling window manager (including myself). Second, you have already probably noticed that such buffers as Emacs Help and friends do not work with Evil properly. And I suspect that the reason for that is the same simply because in case of Emacs Help buffer you could no longer inject this hackish call: (with-current-buffer buffer (evil-normal-state)) I might be wrong with my implications, and I wish you could prove that I am. I'm nowhere near an Emacs hacker, just learning (migrating from Vim), but may I say that defadvice to me seems to be a remedy to this problem? Anyway, please, share your thoughts on this topic, I really hope that this can somehow be reimplemented in more robust way, so that Evil has more seamless and natural integration with the whole Emacs environment. Kind regards, Haroogan

1 0

evil-lookup-func settings in evil-mode
by Hongxu Chen 24 Jun '13

24 Jun '13

Hi, I am writing some c code with Emacs evil-mode and I find that now and then I need to lookup the man pages. It is easy enough when in Evil normal state, by pressing `K', which invokes `evil-lookup'. However the funcall is specified by `evil-lookup-func', so eventually the function called is Emacs function `woman' rather than `man'. The problem is that woman sucks for some formats of manpages, for instance, the table in the manpage of `man', and she also displays margin between words poorly. So I hope to set `evil-lookup-func' to `man'. But I CANNOT since the definition in man.el(.gz) tells me that `man' takes ONE argument. So I re-bind `K' for myself: (evil-global-set-key 'normal (kbd "K") 'man) Everything goes well until I find that in some modes, `Man-mode' for example, this keymap doesn't work; `K' in such case still mapped to `evil-lookup'. So what can I do to avoid calling WoMan by mistake? -- Regards, Hongxu Chen

3 2

TAB goes crazy in C/C++ mode
by Sanel Zukan 05 Jun '13

05 Jun '13

Hi all, I'm not sure is it me (again) but with the recent pulls my TAB in C or C++ mode goes mad sometimes, especially if there are some unusual C or C++ constructs. Here is some example: --- #include <stdio.h> #include <some-lib.h> MAGIC_MACRO(X) class Foo : public Baz { private: int a; int b; <-- sometimes evil gets confused and will not allign this variable, but will put it on the begining public: }; --- When above happens, TAB no loner works (to align the code), unless I change the mode. Even worse, not every mode change will return TAB behavior: e.g. going to fundamental mode will do nothing, but if I go to python-mode, things are restored. Any idea what is going on? This bug is not always reproducible, making it quite hard to explain steps. My emacs is 24.2.1 (x86_64-redhat-linux-gnu) in daemon mode from terminal. PS: I'm seeing TAB is bind to evil-jump-forward so I assume this is more Evil bug than Emacs, as someone on Emacs list would already notice it. Thanks, Sanel

2 1

Evil and latest Undo Tree incompatible
by Barry OReilly 04 Jun '13

04 Jun '13

Undo Tree changed undo-tree-visualizer-map to undo-tree-visualizer-mode-map. The attached patch updates Evil and Evil's undo-tree.el.

2 1

[PATCH] Fix for issue #301
by Max Mikhanosha 02 Jun '13

02 Jun '13

From e4b59630cf40106d9afaf3544094dc27e3a2e840 Mon Sep 17 00:00:00 2001 From: Max Mikhanosha <max(a)openchat.com> Date: Sun, 2 Jun 2013 18:03:27 -0400 Subject: [PATCH] In (evil-define-key) is done for a minor mode, try to arrange for `evil-normalize-keymaps' to be called when mode is toggled --- evil-core.el | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/evil-core.el b/evil-core.el index 18e88d6..662cf0e 100644 --- a/evil-core.el +++ b/evil-core.el @@ -866,6 +866,16 @@ (defun evil-overriding-keymap-state (map) (t state)))) +(defun evil-maybe-hook-minor-mode (keymap) + "If KEYMAP belongs to a minor mode, add `evil-normalize-keymaps' to mode hook" + (when (and (symbolp keymap) + (string-match "^\$.+\$-\$?:map\\|keymap\$$" + (symbol-name keymap))) + (let ((mode-symbol (intern (match-string 1 (symbol-name keymap))))) + (when (memq mode-symbol minor-mode-list) + (let ((hook-symbol (intern (format "%s-hook" mode-symbol)))) + (add-hook hook-symbol 'evil-normalize-keymaps)))))) + (defmacro evil-define-key (state keymap key def &rest bindings) "Create a STATE binding from KEY to DEF for KEYMAP. STATE is one of `normal', `insert', `visual', `replace', @@ -898,7 +908,8 @@ (defmacro evil-define-key (state keymap key def &rest bindings) (setq key (pop bindings) def (pop bindings))) ;; ensure the prompt string comes first - (evil-set-keymap-prompt aux (keymap-prompt aux))) + (evil-set-keymap-prompt aux (keymap-prompt aux)) + (evil-maybe-hook-minor-mode ',keymap)) 'after-load-functions t nil (format "evil-define-key-in-%s" ',(if (symbolp keymap) keymap 'keymap)))) -- 1.7.11.rc0.100.g5498c5f

1 1

[PATCH] Continue with last-insertion tracker if buffer region is valid
by Trevor Murphy 01 Jun '13

01 Jun '13

Hey, all. Sorry to post this to the mailing list without something on the bug tracker, but bitbucket apparently has stopped taking OpenID and I don't think this report merits creating a whole new account and password. Commit db7e641 resolved Bug #272, "Evil works incorrectly with yasnippet near the end of buffer". The issue was that `evil-stop-track-last-insertion' would get confused if the last insertion appeared to extend past the buffer bounds, and the solution was to put in a guard. However, I think the guard is doing `<' and `>=' comparisons backwards. As in, shouldn't it be like the attached patch? Thanks, Trevor Murphy (1): Continue with last-insertion tracker if buffer region is valid evil-common.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 1.8.3

2 2