WIP fix #565 : cursor motion in insert mode should affect .

[jacekkopecky]

Fixes most of #565 except when I click in the editor, vim-mode doesn't notice. I don't know yet how to fix that, but this PR is better than nothing I guess. 8-)

[jacekkopecky]

Rebased to current state of the art, cleaned up.

[bronson]

This PR introduces a bug: bronson/vim-mode-next#4

Also, even though it's more Vim-ish, I'm personally not enthused about right-arrow in insert mode no longer wrapping to the next line... Maybe make it be a setting? wrapLeftRightInsertMotion, different from wrapLeftRightMotion?

[jacekkopecky]

Quite right, sorry about that. Working on a fix.

About the wrapping, @bronson, do I understand correctly that you have wrapLeftRightMotion off, and yet want that motion to wrap in insert mode?

[bronson]

Yes, I said that, but I take it back. Sorry. :)

That's how my workstation's Vim works -- normal mode doesn't wrap, insert mode does. But I'm on my laptop now, and neither mode wraps. Since I haven't noticed the difference until now (we're talking years probably...), I guess I don't care much after all.

I'll get used to whichever way vim-mode settles on. And I definitely vote to NOT implement whichwrap!

[jacekkopecky]

Fixed bronson/vim-mode-next#4 , but need to postpone rebasing to master for now. This PR is related to #609 and should be considered together, and that one needs maintainer guidance.

[bronson]

Fix looks great! Added this PR back to latest vim-mode-next, 0.54.15.

[bronson]

This PR conflicts with autocomplete-plus.

When the completions are shown, I hit down arrow to move to the next completion. Instead, vim-mode:move-down-insert fires, turns off the autocompletions, and moves one line down in the buffer.

Putting this in keymap.cson makes it work again but obviously isn't a fix:

'atom-text-editor.vim-mode.insert-mode':'up':'unset!''down':'unset!'

[jacekkopecky]

Thank you, good catch. If we find other similar interactions, we can start thinking about how to address this in a less case-by-case way.

[jacekkopecky]

Forgot to say explicitly: I added a fix for the autocomplete issue. 8-)

[bronson]

Yeah, the not(.autocomplete-active) clause might turn into not(.autocomplete-active|.doc-hints-active|.weatherbug-active|.j-random-plugin|.etc). (And autocomplete might suddenly want to start using left/right...)

That said, hopefully there won't be a lot of plugins popping up distractions while typing. This could be good enough.

Fix is in v-m-n 0.55.1, looking good.

[jacekkopecky]

Yes @bronson, that's exactly the issue that one immediately imagines. I suspect, though, that due to life being how it is, interactions with j-random-plugin would need some other workaround. Notice how only up/down is in not(.autocomplete-active) and not left/right; I'm sure j-random-plugin will have a different conflicting set. As they say - one is an incident, two is a coincidence, and three's a pattern. I'd like to postpone trying to generalize until I see a pattern. If Atom provides one, I'd love to know about it.

[jacekkopecky]

I just realized this approach to fixing #565 isn't right - I've only taken into account arrow-key motions but not any other motions than can happen in insert mode (pgdn, end etc.). I'll redo this PR with onDidChangeCursorPosition.

[bronson]

Does it make sense to just fix #565 here and do the cursor motion fixes in another PR?

Also, mouse doesn't seem to interrupt insert mode either... Just wondering if you thought about it and found the fix was too ugly.

[jacekkopecky]

@bronson fixing it with onDidChangeCursorPosition will be one fix for any motion, including mouse clicks. I have 30e4073 (a biggie) and #767 (a small one) in the queue before I can get to this one.

[bronson]

I hear that, first things first. I was just wondering if that would be an easy way to make this PR smaller / easier to merge?

My random thinking... I care a lot about fixing giant undos, but not much about forcing the insert cursor to stay on the same line. (Actually, once insert-mode cursor positioning lands, I'm going to figure out a way to turn it off on my machine... Turns out I really do like insert mode feeling just like Atom. I know, I'm waffling like crazy on this one!)

[jacekkopecky]

@bronson I'm not sure what you mean about cursor positioning there

[bronson]

Sorry, let me back up... This PR does two things, right?

• ensures arrow key motion (and hopefully mouse clicks) interrupt insert mode keeping undos small
• restricts the cursor to the current line using keymaps now, and hopefully onDidChangeCursor position in the future

Just curious if it would help mergeability to split these two behaviors into separate PRs. (ordered of course -- one would have to be applied before the other)

[jacekkopecky]

Ah I see, I'd forgotten about restricting left/right motions in case wrapLeftRightMotion is off.
I've been trying to do the interrupting of undo with onDidChangeCursorPosition but it's a huge pain - of course Atom will report a cursor position change on every input (at least it says the cursor motion was caused by text change, except backspace doesn't report the motion was caused by text change); and bracket-matcher's insertion of () when the user types ( also causes a cursor motion.

At the moment I'm thinking that some departure from VIM is warranted here - perhaps insert undo should work like normal, non-vim-mode, typing undo?

My littlest one has been keeping me busy these days but soon I should be able to make an alternate PR to show what I mean.

[bronson]

Sure, vim-mode undo working just like Atom undo sounds fine to me. Atom's undo grouping used to be atrocious but seems pretty good now. As long as the entire insert session doesn't get grouped into a single undo, I'd probably be happy with just about anything.

[lee-dohm]

As stated in the README, this package is no longer maintained and is deprecated. We recommend that people use the vim-mode-plus package instead. Because of this, we are archiving this repository and closing all issues and pull requests. Thanks very much for your support and contributions!