period (`.`) after change command (in visual mode) doesn't redo it properly

[ssfrr]

To reproduce:

1. Type some text.
2. put the cursor in the text, press vlll to select some of it
3. type cabcd<esc> to change the selected text into abcd
4. move the cursor to some other part of the text and press .

Expected result: the 3 characters after the cursor get changed into abcd

I haven't nailed down exactly what it is doing, but it's not the expected result. Sometimes I see text just deleted, or the cursor jumps back to the first place I did the change command.

[winstliu]

What version of Atom is this, on what OS?

[ssfrr]

Atom 1.0.0, vim-mode 0.54.0, tested on Ubuntu Trusty and OSX Yosemite

[ssfrr]

I just tested with some other change commands include cw to change a word and cf_ to change everything up to an underscore and they repeat correctly with ., so I think this issue is limited to visual mode.

[bronson]

Yep, this is happening for me 100% of the time. Here's the description I just wrote up thinking I'd found a new bug:

• viw to select a word
• hit s or c and replace it with 4 characters (or whatever). Hit esc.
• move to another part of the file
• hit . to repeat the replacement

what should happen: the 4 characters starting at the cursor are replaced by the new text

what does happen: the cursor jumps back to the last character of the replaced text and deletes 4 more characters after that character. If you keep hitting ., 4 more characters keep disappearing until you reach the end of the line.

[jacekkopecky]

@bronson you wrote 4 characters should be replaced by the new text, and you only mention 4 characters as the size of the new text - do you mean that the length of text replaced by . should match the length of the new text?

The way I understand it, and checked in MacVIM now, is that s or c in visual mode that has selected <x> characters (e.g. 5) is repeated as c<x>l, e.g. c5l. The number of characters to disappear matches the length of the original selection, not the length of the new text. In linewise visual mode that selects <y> lines, a c is replayed as c<y-1>j.

I'd be happy to look into this when the maintainers come back from holidays and reduce the queue of my other PRs. Or shall I just do that for the benefit of vim-mode-next? (Which is a laudable effort!)

[ssfrr]

Agreed. In @bronson's comment I think that "the 4 characters starting at the cursor" should be "the N characters starting at the cursor, where N is the length of the original selected word".

For my own selfish impatience I'd be grateful if this made it into vim-mode-next. 😄

[bronson]

Exactly right @jacekkopecky and @ssfrr, that's what I meant. Yes, the deleted text appears to be the length of the original selection as long as it doesn't cross a line break (for each line in the selection).

A fix would be incredible, I would merge it into vim-next in a heartbeat.

[jacekkopecky]

Thanks @bronson, I was missing an interesting case: c of a characterwise visual selection that crosses <x> line breaks will, when replayed with ., delete like this: until the end of the current line (however long it is), any number of whole lines (<x-1>), and the exact number of characters originally selected on the last line, up to (and including) the \n on the last affected line.

Well, that's probably not clear, so here's how you can try it out:
Put this in VIM:

123456789
abcde
fghijklmnopq
uvwxyz

1. put cursor on c,
2. visually select until (including) m
3. c to change it to foo (now the second line in the window will be abfoonopq)
4. u undo so we have four lines again
5. move cursor to b
6. . to redo the change (now the second line in the window will be afoonopq)
7. u to undo again
8. move cursor to 2 on the first line
9. . to redo the change, now the first line will be 1foofghijklmnopq

The last part is weird to me, I'd expect the last line break to stay there, ending with 1foo on the first line, and fghijklmnopq on the second line. Any thoughts or preferences? It will affect the code. I'd be happy to stray away from accurate replication of VIM here.

So a question to everyone: how should vim-mode behave here?