April 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

Colorscheme
by satshabad khalsa 26 Apr '13

26 Apr '13

Hi all, I was thinking about making the switch from vim to emacs and use the evil-mode for editing? Is it possible/easy to port my custom color scheme to emacs? Thanks, Satshabad

2 1

Any existing way to customize derived mode according to its base mode?
by Hongxu Chen 25 Apr '13

25 Apr '13

Hi all, Evil mode is really wonderful for most editing issues. But I sometimes prefer the default keymaps(emacs state) for other modes for instance, those modes that are derived from comint-mode. When I set (evil-set-initial-state 'comint-mode 'emacs) But when I use gud-mode, the initial state is still `normal'. So is there any setting that can make the derived mode inherit the base mode? Thanks. Hongxu Chen

2 2

is ":norm ..." available?
by Qiming Sun 24 Apr '13

24 Apr '13

Hi all, I'm just starting to use Evil. In Evil, I didn't find the Vim function ":norm" e.g. :%norm 3J to join every 3 lines for the entire file. Is it available in Evil now? Or is it a future plan? Thanks, Qiming

2 1

Non editing Evil commands in evil-normal-state-map
by Barry OReilly 08 Apr '13

08 Apr '13

Modes in which direct editing of text isn't sensical generally initialize in motion or emacs state. This means that the evil-normal-state-map is inactive. But there are some useful Evil commands in evil-normal-state-map that don't involve editing text, such as: evil-record-macro what-cursor-position find-file-at-point evil-quit and several others. These are unavailable in for example Buffer Menu, even though they would make sense there. What's the reason behind putting non editing commands in evil-normal-state-map?

2 2

Strange behavior after hibernate
by Sanel Zukan 07 Apr '13

07 Apr '13

Hi all, Maybe someone can help me to indentify this odd issue I noticed after recent pull and Fedora upgrade. I'm using Fedora 18 x86_64 with Emacs 24.2.1 in daemon mode, from terminal. When I send OS to hibernate state (with 'systemctl hibernate') and leave terminal open with emacs editing session, after resume, Evil (sometimes) became confused and almost all shortcuts get messed up. For example, in normal mode, 'gg' when pressed for the first time will go to the first line, but pressed again will invoke emacs 'Goto line:' command; or maybe pressing '$' will go to the end of the line, but pressing '0' will do nothing; pressing '0' again will send it to Emacs but not Evil since Emacs will report 'ESC 0 0 0 0' in command line after some time. Evil reload will return mode back to normal operation. Also Emacs behaves quite normally. Any idea what is happening? Does Evil has any global timers that could probably be messed up after resume? Best, Sanel

1 0