emacs-evil / evil

The extensible vi layer for Emacs.
GNU General Public License v3.0
3.34k stars 282 forks source link

change inner word does not work with repeat (dot) #296

Closed TheBB closed 7 years ago

TheBB commented 11 years ago

Originally reported by: Anonymous


In vim, if I am in the middle of a word in normal mode and I type "ciw" and then type a new word, the new word will replace the word I am in, for example:

bit[curosr]bucket

"ciwfoobarESC"

will leave:

foobar

This part words fine in evil :)

Then, still in vim, if I go to the middle of another word and hit ".", that new word will be replaced with "foobar" since my last vim "command" I guess is "change inner word foobar ESC".

someoth[cursor]erword

"."

foobar

In evil, when I hit dot (evil-repeat) foobar is simply inserted at the cursor location and the "change inner word" part doesn't get executed first.

I actually do this all the time, so its pretty noticeable to me -- of course everyone uses vim commands differently -- someone else may never notice. I'm guessing though that if ciwfoobarESC is busted there may be other similar kinds of commands that also don't quite work with dot like they are supposed to.

Thanks!


TheBB commented 11 years ago

Original comment by Frank Fischer (Bitbucket: lyro, GitHub: lyro):


Yes, keychoord and evil may interfere because operator state does its own key parsing. Maybe evil will once have a similar build in feature that works well with other parts evil.

TheBB commented 11 years ago

Original comment by igoodrich (Bitbucket: igoodrich, GitHub: igoodrich):


The problem was a specific keychord binding I was using. I was emulating vim unimpaired's use of [ and ] to go to next/previous of whatever. So, to go to the next and previous git change, I had this pair of bindings:

(key-chord-define evil-normal-state-map "]c" 'git-gutter:next-hunk) (key-chord-define evil-normal-state-map "[c" 'git-gutter:previous-hunk)

This somehow (as I can easily imagine) interfered with the normal mode use of 'c'. So, keychord + evil while a fantastic combination is definitely more than enough rope to hang oneself with.

Next time I will follow the bug report guidelines and test on a vanilla version before submitting.

Thank you for the fast response and the utterly outstanding mode.

TheBB commented 11 years ago

Original comment by igoodrich (Bitbucket: igoodrich, GitHub: igoodrich):


I cloned master from the github mirror and did a make terminal. In that setting, I agree the issues does not occur and I can't repeat it either. Now that I know its not evil I'll dig in and try to figure out what's up and post back here if I find something.

FWIW, I did notice, probably unrelated though a little suspicious, that, this test failed:

F evil-test-repeat-error | Test whether repeat returns to normal state in case of an error. | (ert-test-failed | ((should | (string= | (buffer-substring | (max ... ...) | (point)) | before)) | :form | (string= "yy" "xxxline 1\nline 2\nyy") | :value nil))

TheBB commented 11 years ago

Original comment by Frank Fischer (Bitbucket: lyro, GitHub: lyro):


I can't reproduce this. Please follow the guideline for bug reports, i.e. provide a minimal example starting with a clean evil environment (make emacs) so that we can reproduce the problem.