May 2014 - 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

Including Evil in GNU ELPA
by Stefan Monnier 19 Jul '14

19 Jul '14

I remember asking this a few years ago, but somehow I can't seem to find the answer. So here it is again: I think it would be great to include Evil in the GNU ELPA archive. Would Evil's maintainers be interested in doing so? If yes, then please get in touch with me, so we can work out the details (which mostly have to do with copyright paperwork, since we have the same policy for GNU ELPA as for Emacs, to make it easy to move code between the two). Stefan

4 5

Wrapping paredit-forward
by Nikolai Weibull 29 May '14

29 May '14

Hi! How should I go about wrapping paredit-forward so that it will work in normal mode? The problem currently is that once you hit a ‘)’ at the end of a line you can’t go forward any more, as point will be /at/ the ‘)’, due to the way Evil works, not /after/ the ‘)’, as paredit expects it to be.

2 4

Last character in visual selection remains unhighlighted
by Leo Alekseyev 28 May '14

28 May '14

Hi all, It seems that a lot of the time, visual selection for me is visually off by one character. For example, consider the following line, with the cursor at BOL. (123) If I issue commands like "vf)", "v%", I end with the closing paren under the cursor, but the visual mark will NOT include the closing paren, and will only include the first 3 characters, "(123". Now, it is important to note that if I then try to yank the selection, the yanked region is exactly what it should be, i.e. it will include the closing paren. As such, this defect for me is purely cosmetic, but a little annoying. Is this a known issue? Is it possible there is some misconfiguration on my part? Thanks, --Leo

5 7