`cw` shouldn't consume space after current word about amvim-for-vscode

For anyone wanting to follow along at home, I have a fix available on cw-special-case at https://gitlab.com/crussell/amVim.git

Why are you taking fixes but changing the committer ID to your name, and assigning bugs that already have fixes to yourself instead of either accepting the existing fix or discussing the changes?

[aioutecism]

@ghost
Sorry, I don't know how to merge commits from outside github, so I just copied them by hand.

[aioutecism]

About the assignment, I used it to identify that I might need to check the issue sooner.
This is misleading and I removed all those assignments.

[aioutecism]

I just realized I could add a new origin and merge branch from it!
I'll do this next time.

This is ready to merge with 0.1.1 now. git pull https://gitlab.com/crussell/amVim.git cw-special-case

[aioutecism]

Please give me some time to check this one.

[aioutecism]

I'm not sure about passing actions' args to motions.
It can make the input -> action -> motion flow harder to control and understand.

How about passing isChange: boolean to ActionDelete.byMotions and then deal with it like isInclusive?

The problem is we need to be able to select the correct behavior for w at some point before it gets added to the motions array. By the time we get to ActionDelete.byMotions, we've already created the motion, which means it can only follow the normal semantics for w (i.e., NEXT_START).

Whatever fix we take for this is probably not going to be very clean. It's a special case where Vim itself, intervenes to rewrite the rules about what w is supposed to mean.

If you don't want all the args getting merged, what about allowing commands to pass an optional set of args forward to the motion? We would be able to select the appropriate semantics that way. It would work the same as my current change does, except it would happen through an extra sidechannel, instead of creating a single set of coalesced args. Bindings that never use the sidechannel wouldn't be affected. This actually does end up sounding pretty clean to me.

[aioutecism]

The option param of motions' apply function is intended for special case like this.
I think we don't need to implement another way to deal with special cases unless it is impossible with the current one. (And if that is the case, we should eliminate the option param and change it to the new way.)

https://github.com/aioutecism/amVim-for-VSCode/blob/master/src/Motions/Motion.ts#L15

Okay, I used option instead.

https://gitlab.com/crussell/amVim/commit/9672a0adbbb91dee91af910d8beff999c2506563

I'm not calling it isChange anymore. I was writing some code comments to clarify that it wasn't for general purpose use and there shouldn't really be any other reason to use it, but then I just named it cwNeedsFixup instead. It's more self-documenting that way, and I can leave out the comments.

Note that this is a different branch (cw-new). I branched off the old cw-special-case to avoid committing changes that would have just reverted what was in the other commit.

[aioutecism]

Thanks for the fix.
Merged d7c0494.

[aioutecism]

Also, I'm thinking using getWordRangeAtPosition from VSCode's API to do word motion.
Maybe next time.