Add CamelCaseMotion plugin

[jkillian]

What this PR does / why we need it:

Adds a CamelCamelCase motion plugin inspired by https://github.com/bkad/CamelCaseMotion. Adds support for the following motions when enabled:

• Move to next camelCase word segment: <leader>w
• Move to end of camelCase word segment: <leader>e
• Move back to beginning of camelCase word segment: <leader>b
• Change/delete/select whole camelCase word segment: <operator>i<leader>w commands.

In addition to camelCase, the plugin should also work correctly for snake_case.

Which issue(s) this PR fixes:

Fixes #1220
Fixes #2808 (likely)

Special notes for your reviewer:

• There's a gnarly regex in there that's admittedly hard to review, but it's well-documented and can be played around with in Regex101 if using the latest Chrome. I chose to use a regex instead of trying to use VSCode's built in subword navigation or some other mechanism because it made the rest of the implementation quite clean and similar to existing motions.

• The aforementioned regex uses some lookbehinds, and thus requires Node 9.0+. This shouldn't be a problem since the latest VSCode bundles Node 10.2. I did bump the docker image to use Node 10 as well for consistency, though I'm not sure this was strictly necessary.

Let me know if any changes to this PR are needed! Hope you don't mind getting a PR for this feature out of the blue 😄

[jpoon]

Dope!

[jpoon]

I'm wondering if we should move away from having position.ts the dumping ground for all positioning related logic as it's a bit of a mess.

As the changes you introduced to this file are specific to camel case, I wonder if we should create a new file under /plugins camelcase.position.ts?

What do you think?

[jkillian]

I'm not opposed to the idea in principle, but if I were to move I'd either have to duplicate or make public all the get*Word*WithRegex functions and maybe the getAllPositions family of functions since they're shared among all the word-based motions. Your call, I'm happy either way!

[jpoon]

Ermagod. Thank you for writing comments.

[jkillian]

Thanks for the quick review @jpoon! I'll make these changes a bit later today

[jkillian]

Made CR changes! Though I didn't adjust Position yet until we decide if that's something we definitely want to do

[jpoon]

We can skip the position refactoring. Left one tiny comment if you could address. LGTM otherwise.

[jpoon]

I'm trying to make this more hierarchic. Can you make this vim.camelCaseMotion.enable instead? Such that if we do end up creating more configs for camel case, they can live under vim.camelCaseMotion

[jkillian]

Good idea! I've switched the setting over as you suggested and pushed the new changes.

[TravisBuddy]

Hey @jkillian,
Something went wrong with the build.

TravisCI finished with status errored, which means the build failed because of something unrelated to the tests, such as a problem with a dependency or the build process itself.

View build log

TravisBuddy Request Identifier: 4d2d4a10-32f9-11e9-909a-37b9af0e35d8

[ELLIOTTCABLE]

Is there any way to configure the keybinds of this PR?

(Also, freakin' AWESOME.)

[jkillian]

Glad you like it @ELLIOTTCABLE 😄

You should be able to change the keybindings following the docs here.

For example, to make \ x move by a camel case word, I could add something like this to my VsCode settings.json:

    "vim.normalModeKeyBindingsNonRecursive": [
        {
            "before": ["<leader>", "x"],
            "after": ["<leader>", "w"]
        }
    ]

You can also modify the vim.leader setting if you simply want to change what key <leader> maps to.

[ELLIOTTCABLE]

Ah! Any issues you forsee with using this to remap the default motion to being by-camelcase?

    "vim.normalModeKeyBindingsNonRecursive": [
        {
            "before": ["w"],
            "after": ["<leader>", "w"]
        },
        {
            "before": ["<leader>", "w"],
            "after": ["w"]
        },
    ]

[jkillian]

Not entirely sure @ELLIOTTCABLE, I'd say give it a go and see how it works for you 😄 One thing that might be tricky is remapping ciw so it works as if you said ci<leader>w. Had trouble getting that to work when I tried it out

[ELLIOTTCABLE]

Ugh, that's a good point. And unfortunate. Might need integrated support to pull off operator-motions. v.v

[gapop]

@ELLIOTTCABLE did you eventually find a way to bind camel case motion to the default keys and have composed commands working?

[berknam]

@ELLIOTTCABLE did you eventually find a way to bind camel case motion to the default keys and have composed commands working?

Once PR #4735 gets merged it will allow you to do operator-pending mode remaps so you will be able to do this:

"vim.operatorPendingModeKeyBindingsNonRecursive": [
  {
    "before": ["w"],
    "after": ["<leader>", "w"]
  },
  {
    "before": ["<leader>", "w"],
    "after": ["w"]
  },
]

It needs to be non recursive otherwise it would loop between the two until 'maxmapdepth'. Also bear in mind that this will work well with PR #4735 but after PR #4995 gets merged this won't work because the <leader>w won't be an action itself anymore but instead a remap to <Plug>CamelCaseMotion_w. So after that PR you will have to do this:

"vim.operatorPendingModeKeyBindingsNonRecursive": [
  {
    "before": ["w"],
    "after": ["<Plug>CamelCaseMotion_w"]
  },
  {
    "before": ["<leader>", "w"],
    "after": ["w"]
  },
]