Use iedit as back end for symbols and selections edition

[syl20bnr]

See discussion on #101.

The idea is to keep ahs for highlight and scoped navigation and iedit for highlighted symbols and selections edition.

This implies:

• [x] adapt ahs micro-state to remove the edition part
• [x] add iedit to MELPA repository
• [x] add iedit to spacemacs layer
• [x] <SPC> s e bound to iedit commands
• [x] if some features can of iedit can be toggled dynamically then create a micro-state for it

[CestDiego]

Yes! totally aproved.will this keep ahs when not in selecting a region to edit though?

[syl20bnr]

Nope, if there is no selection then <SPC> s e will select the symbol under point and fire iedit. The current behavior will still work then, but with iedit backend. This is the simplest way to keep the edition of occurrences consistent.

[CestDiego]

yes I this this would be great

[syl20bnr]

@CestDiego @danielwuz Can you test the iedit layer ?

[danielwuz]

Just tested. It is a huge improvement over the stock iedit-mode! Thanks for working this out.

Here's some of my thoughts:

1. Don't bind b to blank out occurance. The same reason and hjkl keys, people often use b for navigation. See below example:

h|ello world
hello world

usually I do viw to select current region, my cursor will stop at last letter of hello(letter o), then SPC s e to select all occurences, but then my cursor will move 1 position forward, in this case, will be on space. Then I always want to jump back to begining of the word by b, then I messed up.

2. In my opinion, r is less useful because I almost always operate on text object, i.e. ciw in iedit micro state. I like using text object because my thought doesn't have to switch between other evil state and this micro state. Maybe we can consider bind make all occurrences blank to r for remove?
3. Can you add that with universal prefix C-u before #, one can set the start value of increasing number sequence?

Thanks,

[danielwuz]

Actually, I think it would be a good idea of keep default vim keys as they are. For instance, r for replace current letter, s for deleting current letter and entering insert state. w for going to next word.

The idea is to make iedit-mode seamless with other mode. How do you think?

[syl20bnr]

@danielwuz I know how you feel. I did went to the same route as you described with evil-lisp-state and it was a mistake. In this new state I voluntary omit a lot of normal state bindings because the point of iedit state is to interface iedit features which are tailored for occurrences replacement. Though you can see in the README that sometimes I put some normal state keys for convenience (which I explicitly wrote) and you were right that we need at least hjkl navigation. To go back to the beginning of the occurrence N does the trick which I wrote too in the README, I know that it is not the Vim way but I feel that it is just a matter of a few days to get the muscle memory of occurrences replacement.

Even shorter because today I used a lot the r binding and it feels already almost automatic: SPC v v e r boum! I'm ready to enter the replacement and now hit fd to exit.

So I won't make the same mistake as with evil-lisp-state, that is making an extended normal state. iedit state is a micro state but implemented as a evil state.

[danielwuz]

I see your point. I think it's just a matter of habit. I'll get used to this keys over time =)

Will you mention the C-u thing in README as in # 3? It should be useful to start index with arbitrary numbers.

[danielwuz]

maybe consider also bind C-g to evil-iedit-state/quit-iedit-mode, as ESC does?

[syl20bnr]

I am once again divided on this extended normal state thing :-) I may give it another try...

[syl20bnr]

@danielwuz So thanks to your feedback I will push a new version which is exactly the opposite of what I said, that is... a normal state adapted for iedit.

[syl20bnr]

This is in develop.

[syl20bnr]

The layer is in good shape to me now, closing this issue.