Originally reported by: Anonymous

If I select more than one line of text, and then use "<<" to unindent the block of text, I expect to then be able to use the "." dot operator to repeat the unindent on the previously selected text block. Instead, only the current line is unindented when the dot operator is used.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/32

Originally reported by: Michael Markert (Bitbucket: cofi, GitHub: cofi)

Both are bound to `evil-complete' and do the same, instead of trying the following respective the previous candidates first.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/22

Originally reported by: tass (Bitbucket: tass, GitHub: tass)

In customize-group, ruby indent level is set to 2. But if I indent by typing ">", 4 spaces are inserted.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/24

Originally reported by: Anonymous

It would be nice if typing Y in normal mode copied text from the cursor to the end of line instead of copying the whole line, for the sake of consistency with other operators such as D or C.

I know this isn't how VIM works, but it would be nice to at least have a customization setting available to make this behavior more consistent.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/31

Originally reported by: Michael Markert (Bitbucket: cofi, GitHub: cofi)

A dk kills the current line and the line above, d<up> should do the some but kills from point until the char directly above the point.

Examples (| denotes the cursor):

;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, visit that file with C-x C-f,
;; then |enter the text in that file's own buffer.

dk}}} →
{{{dk

;; This buffer is for notes you don't want to save, and for Lisp evaluation.

;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, visit that file with C-x C-f,
;; then |enter the text in that file's own buffer.

d<up>}}} →
{{{d<up>

;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If yo|enter the text in that file's own buffer.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/46

Originally reported by: Anonymous

Is there a way to enable hjkl keys in vi/evil normal mode to correspond with apparent line breaks in visual-line-mode in emacs?

• Bitbucket: https://bitbucket.org/lyro/evil/issue/13

Originally reported by: Ramana Kumar (Bitbucket: xrchz, GitHub: xrchz)

So far it looks like the /\ (or /) digraph, which should produce × is missing. If I find more missing ones, I'll happily add them, if it's easy enough, if someone wants to show me the way once.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/41

Originally reported by: Frank Fischer (Bitbucket: lyro, GitHub: lyro)

Key-bindings involving a meta-key, e.g., M-x, do not work in terminal mode. The reason is that the (kbd "ESC") binding is overwritten in evil-maps.el, but all bindings with meta-key in terminal mode are signalled with ESC as prefix key.

Therefore some special magic has to be done intercepting the ESC key when used as prefix-key. viper and vim-mode both do this using some special key-binding on ESC with timeout (look for //vim:intercept-ESC-mode// in //vim-keymap.el// of vim-mode's source).

Furthermore, in X mode it may be better to bind [escape] instead of "ESC" (in fact, the signal arriving from the system is [escape] which is converted to "ESC") and leave the "ESC" binding unchanged. This way the Emacs alternative of pressing "ESC x" instead of "M-x" should work in X mode, too (in X "M-x" and "ESC x" are different events but the first is eventually remapped to the second, in terminal mode both events are the same, namely "ESC x").

• Bitbucket: https://bitbucket.org/lyro/evil/issue/2

Originally reported by: Anonymous

When I use \C in an evil search, I expect the search to be case-sensitive. As far as I can tell, the \c \C flags currently do nothing. I think I tracked down the problem.

In evil-ex-regex-case, the variable "case" is set to (1- (match-end 0)), the location of the character following the backslash. Then there is a cond expression which tests if "case" is ?c or ?C. This is wrong; it is currently testing if the location is equal to ?c or ?C, not the character itself. There should be a substring into the "re" string to get the character first, then test it in the cond expression. I'm new to elisp so I don't know the exact command.

Thanks!

• Bitbucket: https://bitbucket.org/lyro/evil/issue/36

Originally reported by: Anonymous

In VIM, parentheses are highlighted if the cursor is over either the starting paren or the ending paren.

In Emacs mode, with show-paren-match on, a set of parentheses is highlighted if the cursor is over either the starting paren or one character past the ending paren. Thus, if two sets of parens are directly adjoined:

(parens1)(parens2)

, it is impossible to highlight parens2 by positioning the cursor over its opening paren, because parens1 gets highlighted instead.

VIM does not have this problem since the cursor must be directly over the starting or ending paren to activate the highlight.

However, in Evil, there seems to be a mix of VIM and Emacs behavior:

sets of parentheses are highlighted if the cursor is over either the starting or ending paren, EXCEPT in the above case of directly adjoined sets of parens. In Evil normal state, as in Emacs mode, it is impossible to highlight parens2 by putting the cursor over the opening parens, because parens1 gets highlighted instead. I expected Evil to follow VIM's behavior of highlighting the set of parentheses the cursor is directly over.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/43

Originally reported by: topher200 (Bitbucket: topher200, GitHub: topher200)

The functions evil-scroll-line-to-center and evil-window-middle correspond to the keybindings 'zz' and 'M', respectively.

=== Expected behavior ===

User presses 'zz': the window scrolls the current line to the vertical center of the window

User presses 'M': nothing should happen, since the cursor is already on the center line

=== Actual behavior ===

User presses 'zz': the window scrolls the current line to the vertical center of the window

User presses 'M': the cursor moves one line higher

=== Solution ===
I'm attaching a patch that reduces the window height count by 1 (before dividing by 2) when doing the center calculation in evil-window-middle. It made more sense to modify this function, since evil-scroll-line-to-center gets its functionality by just calling the 'recenter' elisp function.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/44

Originally reported by: tass (Bitbucket: tass, GitHub: tass)

In vim, "*p pastes the content of the X selection buffer. In evil, I simly get an "empty register" error. I suppose register * doesn't know about X selection.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/20

Originally reported by: Michael Markert (Bitbucket: cofi, GitHub: cofi)

It would be great if archive-mode' buffers came in emacs-state or in a modified normal state like dired'

• Bitbucket: https://bitbucket.org/lyro/evil/issue/40

Originally reported by: Anonymous

Hi, I love evil so far! I've noticed though that typing Ctrl-o $ in insert mode falls short of the end of line. Ctrl-o 0 seems to behave as expected and moves cursor to beginning of line. Thanks!

• Bitbucket: https://bitbucket.org/lyro/evil/issue/12

Originally reported by: Michael Markert (Bitbucket: cofi, GitHub: cofi)

In vimpulse I could define a key for a mode that is not already loaded.

Now I have to use `evil-define-key' on a real keymap, i.e. the keymap must already be defined and thus the file loaded.

This leaves me with either

• use a mode-hook
• use eval-after-load.

Both are not really satisfying.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/4

Originally reported by: York Zhao (Bitbucket: york, GitHub: york)

This is a problem introduced in recent commits. The emacs modes that previously
would be brought up in motion state now end up in normal state. An example being
the "Info-mode", which is supposed to be brought up in motion state now end up
in normal state.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/49

Originally reported by: Michael Markert (Bitbucket: cofi, GitHub: cofi)

Toggle input method (-> on)

Enter insert state

Toggle input method (-> off)

Exit insert state

Enter insert state, input method is still turned on

Bonus:\
6. Exit insert state\
7. Toggle insert state (-> off)\
8. Enter insert state, input method is still turned on\

So toggling input method in insert state doesn't last and breaks toggling in the buffer.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/15

Originally reported by: Frank Fischer (Bitbucket: lyro, GitHub: lyro)

The current version of evil-execute-repeat-with-count only deals with keystrokes.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/9

Originally reported by: phzbox (Bitbucket: phzbox, GitHub: phzbox)

Hi, usually in Vim : jump to the line. However, it says: "Invalid ex-command"

gg or G work well though.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/25

Originally reported by: Anonymous

you do "cat" or "dat" or "cit" or "dit" it does not work correctly.

</head>

For example when I do cat the end result is

</head>

while I think the expected result is

</head>

• Bitbucket: https://bitbucket.org/lyro/evil/issue/23

Originally reported by: legrostdg (Bitbucket: legrostdg, GitHub: legrostdg)

In vim, if I hit "I" "sometext" in visual mode, "sometext" is inserted at the beginning of each line selected in visual-mode. That does not seem to be the case with evil...

• Bitbucket: https://bitbucket.org/lyro/evil/issue/8

Originally reported by: Michael Markert (Bitbucket: cofi, GitHub: cofi)

`evil-complete' completes without respect to case.

Having a buffer with hello Hello' evil-complete' will complete a hel' only to Hello' but never to `hello'.

Vim doesn't behave like this.

I propose to let-bind dabbrev-case-replace/distinction' either to nil' or to a the value of a new var.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/21

Originally reported by: Anonymous

I'm using the most recent evil from git head.

If I go to the last line of a paragraph and type "vip" or "vap", I expect the paragraph under the cursor to be selected. Instead, what gets selected is just the line under the cursor along with the entire following paragraph.

If I type "vip"/"vap" on any other line besides the last line, only the paragraph under the cursor gets selected, as expected.

This error only seems to affect selection--using "dap"/"dip" or other text object commands works as expected.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/30

Originally reported by: Frank Fischer (Bitbucket: lyro, GitHub: lyro)

Commands like ~ which operate by default on the character under point should advance the cursor forward. The current behavior is to keep point unchanged which makes it impossible to press ~ repeatedly to toggle the cases of successive characters.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/1

Originally reported by: Michael Markert (Bitbucket: cofi, GitHub: cofi)

Steps to reproduce:

Open ex commandline, (:, evil-ex-read-command)

Try to complete (tab key)

You see an error: completion--some: Wrong type argument: stringp, nil

\

Rather than error out this should show a complete list of commands.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/16

Originally reported by: phzbox (Bitbucket: phzbox, GitHub: phzbox)

I was trying:

:s/([A-Z])([A-Z]+)/\1\L\2/g

Or without all those \ escaping:

replace ([A-Z])([A-Z]+) --> \1\L\2

Basically, replace any uppercase word by the the same word capitalized (only first letter being capitalized).

The \L is the modifier to do that transformation (Turn upper into lower).

Maybe I was wrong in the way I wanted to do it?

• Bitbucket: https://bitbucket.org/lyro/evil/issue/34

Originally reported by: phzbox (Bitbucket: phzbox, GitHub: phzbox)

Maybe it's already possible, if so sorry for asking. I'm searching a way to bind "jk" to in insert-mode. This, by itself, is not a problem. However, it seems like I can't use j with other letters. (For instance, typing 'jabber' in insert-mode won't work.)

The way it works in Vim is: When I press j, it waits a second or so for the other key; if it's a k, it calls the jk binding. Otherwise, it inserts j and the other letter.

Thanks!

• Bitbucket: https://bitbucket.org/lyro/evil/issue/26

Originally reported by: Anonymous

If I follow a tag in a TAG file using C-] that directs to another buffer, then pressing C-o does not return to the original buffer: it goes to the top of the current buffer, and pressing C-o again says "Mark popped".

• Bitbucket: https://bitbucket.org/lyro/evil/issue/42

Originally reported by: Michael Markert (Bitbucket: cofi, GitHub: cofi)

(cursor on ,)

,foo;}}} --(type "de")--> {{{foo;}}}
{{{,foo;

should be ;

|foo,}}} --(type "db")-->  {{{|foo}}}
{{{|foo,

should be |

So in effect: A deletion/change/... on an word boundary just removes the boundary.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/14

Originally reported by: Anonymous

Hi:
m-. doesn't work to jump to tag. c-] works. but there is no gc-] equivalent which shows you list of possible tags.

(define-key evil-motion-state-map "\C-]" 'evil-jump-to-tag)

• Bitbucket: https://bitbucket.org/lyro/evil/issue/47

Originally reported by: Anonymous

The title basically says it all. I have to use

:s/foo/bar/

eventhough I may want to use another delimiter, like so:

:s,foo,bar,

The reason for that might be, that either foo' or bar' contain
a number of forward slashes, or maybe that a forward slash is
just a PITA to type (like Shift-7 on german keyboards).

In any case, it would be nice to freely chose the delimiter.

Regards, Frank (who doesn't have a bitbucket account)

• Bitbucket: https://bitbucket.org/lyro/evil/issue/27

Originally reported by: Frank Fischer (Bitbucket: lyro, GitHub: lyro)

For some reason evil-repeat-pop does not work anymore. Something is wrong with the integration of the undo-system.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/7

Originally reported by: Anonymous

In VIM, using << and >> moves the text to the nearest multiple of shift-width. In evil, the text is simply indented or unindented by evil-shift-width characters. It would be nice if evil respected EMACS tab stops, or at least indented/unindented up to the nearest multiple of evil-shift-width. I wrote some code for indenting/unindenting to the nearest EMACS tab stop, in case it's useful to anybody:

    (defun indent ()
            "Indent line or region using tab stops."
            (interactive)
            (let ((tabs tab-stop-list))
              (while (and tabs (>= (current-indentation) (car tabs)))
                (setq tabs (cdr tabs)))
              (let ((tab (if tabs (car tabs) (+ (current-indentation) tab-width))))
                (if (use-region-p)
                    (indent-rigidly (region-beginning) (region-end)
                                    (- tab (current-indentation)))
                  (indent-rigidly (line-beginning-position) (line-end-position)
                                  (- tab (current-indentation)))))))
          (defun unindent ()
            "Unindent line or region using tab stops."
               (interactive)
            (let ((tabs (reverse tab-stop-list)))
              (while (and tabs (<= (current-indentation) (car tabs)))
                (setq tabs (cdr tabs)))
              (let ((tab (if tabs (car tabs) 0)))
                (if (use-region-p)
                    (indent-rigidly (region-beginning) (region-end)
                                    (- tab (current-indentation)))
                  (indent-rigidly (line-beginning-position) (line-end-position)
                                    (- tab (current-indentation)))))))

• Bitbucket: https://bitbucket.org/lyro/evil/issue/37

Originally reported by: Anonymous

As the title says. When evil-mode is on, once I have toggled to another input-method(a Chinese input method, specifically), I can't toggle it back to english input method, no matter how many times I press "C-\ ".

But when evil-mode is off, it can be toggled back.

Platform:
gentoo linux

Emacs Version:
23.3 gtk

Evil Version:
the latest version in git repo when I am typing.

From :
Shuai Lin [email protected]

Thank you for the great Evil Project.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/18

Originally reported by: York Zhao (Bitbucket: york, GitHub: york)

This problem have been confirmed by using "make emacs".

The problem is that in org-mode, if you select a region of headlines and use "org-sort" on the region, the headlines will be sorted however the sorted headlines will be combined into one line. For example, I have the following text:

*** headline b
*** headline a

I select these two lines by moving the point to the first line and press "V", "j", then "M-x org-sort", the result will be:

*** headline a *** headline b

Instead of:

*** headline a
*** headline b

If I place the point on the first line and press "C-SPC", DOWN, DOWN, and then press LEFT to move the point to the the end of the second line it will work fine.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/38

Originally reported by: topher200 (Bitbucket: topher200, GitHub: topher200)

=== Expected behavior ===
User enters insert mode and starts typing a function. should yield a new line, with the cursor at the correct auto-indent location.

=== Actual behavior ===
User enters insert mode and starts typing a function. yields a new line, with the cursor all the way to the left column.

=== Observations ===
Exiting insert mode and auto-indenting the code ("==") fixes the problem, which shows that evil knows how to indent the code - it's just not doing it.

Emac's describe-key shows that the function being called for in insert mode is "newline". I would expect it to call "evil-ret". "evil-ret" is called on in normal mode, and its documentation talks about it handling insert-mode.

"customize-group" shows that the "auto indent" variable is set to default. That seems to be working fine- creating a new line by entering insert-mode (with "o" or "O") yields a newline with the cursor in the correct spot.

=== Steps to reproduce ===
Write the first line to a function with nested indentation. Example:

(if (not

and press . Notice that the cursor is on the newline on the far left, as shown here by the "|":

(if (not
|

I would expect the cursor to be here:

(if (not
     |

• Bitbucket: https://bitbucket.org/lyro/evil/issue/45

Originally reported by: Anonymous

Hi,

I have a problem with Evil and ESS (Emacs Speaks Statistics) in visual-mode. More precisely, it's an issue between Evil visual mode and noweb-mode/noweb-font-lock-mode

The issue is that some highlights persist after you escape visual-mode.

To reproduce the error, consider a simple .emacs
;; load Evil
(require 'evil)
(evil-mode 1)
;; load ESS
(load "~/.emacs.d/site-lisp/ess/lisp/ess-site")

Then, open any .Rnw on the net, and use visual mode.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/33

Originally reported by: York Zhao (Bitbucket: york, GitHub: york)

Vegard suggested the following code to achieve text object for omment:

(evil-define-text-object evil-a-comment ()
"Select a comment."
(list (evil-comment-beginning) (evil-comment-end)))
(define-key evil-outer-text-objects-map "c" 'evil-a-comment)

The problem is that this works only for emacs lisp comments but not for C/C++ comments.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/39

Originally reported by: Anonymous

evil-search-forward currently does not support search-offsets. It'd be great if there was support for it (particularly e, which puts you at the end of the match).

From the vim help (:help search-offset):

The offset gives the cursor position relative to the found match:
    [num]       [num] lines downwards, in column 1
    +[num]      [num] lines downwards, in column 1
    -[num]      [num] lines upwards, in column 1
    e[+num]     [num] characters to the right of the end of the match
    e[-num]     [num] characters to the left of the end of the match
    s[+num]     [num] characters to the right of the start of the match
    s[-num]     [num] characters to the left of the start of the match
    b[+num]     [num] identical to s[+num] above (mnemonic: begin)
    b[-num]     [num] identical to s[-num] above (mnemonic: begin)
    ;{pattern}  perform another search, see //;

... snip ...

Examples:

pattern                 cursor position
/test/+1                one line below "test", in column 1
/test/e                 on the last t of "test"
/test/s+2               on the 's' of "test"
/test/b-3               three characters before "test"

Work around for /e for now is:

/test<C-r><RET> 

• Bitbucket: https://bitbucket.org/lyro/evil/issue/50

Originally reported by: Anonymous

When a sexp closes at the end of a line, you can't use eval-last-sexp in normal-state to evaluate it because you can't get to the end of the line.

My solution is this command:

(evil-define-command my-evil-eval-sexp-at-point ()
  "Eval sexp at point. Like eval-last-sexp, but one to the right."
  :repeat nil
  (interactive)
  (save-excursion
    (if (not (eolp)) (forward-char))
    (call-interactively 'eval-last-sexp)))

but I haven't used it much yet, and I don't know if there are edge cases. I have it on :eval and ;v.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/17

Originally reported by: Frank Fischer (Bitbucket: lyro, GitHub: lyro)

Evil does currently not support vim-like delete registers 1,2,3, ...

• Bitbucket: https://bitbucket.org/lyro/evil/issue/28

Originally reported by: Anonymous

(I know I should have posted to gmane - but for the life of me I just cannot figure that site out!)

With only evil-mode running, there's no way of posting to erc except erc-send-current-line, I think. It's normally bound to RET, but evil shadows this. What's the correct way to rebind it for erc mode only?

• Bitbucket: https://bitbucket.org/lyro/evil/issue/6

Originally reported by: Michael Markert (Bitbucket: cofi, GitHub: cofi)

I could reproduce reliably with an input-method. Sadly.

A simple check on repeat-type before funcalling it helps but maybe it's just triaging the symptom.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/11

Originally reported by: Vegard Øye (Bitbucket: epsil, GitHub: epsil)

Michael Markert proposed some code for handling input methods at https://gitorious.org/evil/evil/merge_requests/4. Since I don't use input methods myself, I'm unsure of what the best way of handling them would be. Thoughts?

• Bitbucket: https://bitbucket.org/lyro/evil/issue/5

Originally reported by: Anonymous

After emacs -q, evaluate the following in scratch.

(require 'evil)
evil
(evil-local-mode 1)
t
(evil-local-mode -1)
nil
(setq cursor-type 'bar)
bar
cursor-type
t

Notice that the cursor-type is not 'bar because evil-refresh-cursor resets it in the post-command-loop even though evil mode is not active. evil-refresh-cursor should check if evil-mode or evil-local-mode is true before it starts making changes.

-Gerard

• Bitbucket: https://bitbucket.org/lyro/evil/issue/48

Originally reported by: srhb (Bitbucket: srhb, GitHub: srhb)

Trying to call a macro from within itself yields No previous macro, and then it's impossible to enter macro recording again - Emacs will just state "not defining macro".

To reproduce, make a buffer like so:

Word

Word

Word

Then execute: qqqqqdwj@qq@q: That should clear register q, (start record to q, stop, start record to q again) delete the first word, move a line down, attempt to call the for-now-empty q macro (this is where it fails) then end recording and call q. Expected behavior is that all lines should have their first word removed.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/10

Originally reported by: Frank Fischer (Bitbucket: lyro, GitHub: lyro)

The buffer-local value of post-command-hook should contain the element t so the hooks stored in the global binding are run in addition to the hooks in the buffer-local binding.

From time to time it happens that this element t is somehow removed from the buffer-local value. The consequence is that certain important post-command-hooks are not run anymore, //e.g.//, evil-repeat-post-hook or global-hl-line-highlight of hl-line, thus neither evil repetition nor hl-line work anymore.

A simple (add-hook 'post-command-hook t t t) in the affected buffer fixes this problem.

Currently I do not know how to reproduce this bug, it happened from time to time in LaTeX or C++ buffers. I do not even know if this bug is caused by evil or by some other package.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/19

Originally reported by: Frank Fischer (Bitbucket: lyro, GitHub: lyro)

Starting a fresh emacs with "make emacs", loading a file, say evil-repeat.el and instrument a function, say evil-repeat-start, with C-M-x.

Type a few commands, so that evil-repeat-start gets called, always continue with c.

Deinstrument the function with C-M-x.

Now some keymaps of edebug seem to be still active: e.g., typing "h" leads to an error "evil-repeat-start is not instrumented for Edebug".

Disabling evil with M-x evil-mode and reenabling it seems to resolve this problem.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/35

Originally reported by: Anonymous

In file 'evil-motions.el', 'evil-jump-to-tag' function which is bound to vim's ctrl-], (thing-at-point 'word) doesn't produce the results we're used to from VIM. For instance in C mode DEFINES_WITH_UNDERSCORES are problematic since 'word' doesnt include underscores.

Proposed fix: use to (thing-at-point 'symbol)

• Bitbucket: https://bitbucket.org/lyro/evil/issue/29

Originally reported by: Michael Markert (Bitbucket: cofi, GitHub: cofi)

I set `evil-move-cursor-back' to nil, but It is moved back nonetheless when exiting insert-state.

• Bitbucket: https://bitbucket.org/lyro/evil/issue/3