syl20bnr / evil-iedit-state

Slick Evil states for iedit.
GNU General Public License v3.0
58 stars 25 forks source link

iedit-state and evil-change/evil-delete #8

Open jdwaterson opened 9 years ago

jdwaterson commented 9 years ago

This issue is identical to syl20bnr/spacemacs#3193. I was advised to add it to both repos by @TheBB.

It looks to me like there is a problem when using iedit-state when words are space-delimited (ie, most, but not all of the time).

Specifically, in these cases, the evil-change and evil-delete commands (on keys c and d) drop out of iedit altogether, so my changes are applied at the current cursor position only, and all of the iedit highlighting disappears (although the cursor remains red, so iedit-state still thinks it is active).

Here is an example, showing both working and non-working behaviour. My initial buffer (in fundamental mode) contains just:

foobar.qux
foobar.qux

I move to the "b" in the first foobar, and then hit SPC s e d w. In this case, everything works fine and I end up with:

foo.qux
foo.qux

...which is what I want. On the other hand, if my starting buffer is just one character different, and I replace that first period with a space, viz:

foobar qux
foobar.qux

...and then, once again I hit SPC s e d w then I get dumped out of iedit (highlights disappear) and my buffer looks like this:

fooqux
foobar.qux

I get essentially the same problem if I use c w instead of d w. It looks like a bug to me, but not sure if I'm the only person seeing this behaviour?

My spacemacs setup:

System Info

(emacs-lisp git markdown osx themes-megapack clojure html auto-completion :variables auto-completion-return-key-behaviour 'complete auto-completion-tab-key-behaviour 'complete)
braham-snyder commented 7 years ago

same bug here, for what it's worth

I suspect most people (myself included) don't run into this simply because they use e (or similar) there

System Info :computer: