Camelcase movement operators

[jspahrsummers]

Given the programming languages I typically work in, one of my favorite Vim plugins is camelcasemotion. I'd love to build something similar for Atom, but it seems like it would depend on support within vim-mode directly.

Is there any precedent for implementing non-standard movements like this, or does anyone have recommended reading for building a separate package that relies upon vim-mode?

/cc @nathansobo @ymendel @bhuga @mcolyer

[nathansobo]

I would be open to adding this kind of feature to core, with a subword version of every word-oriented method. So there would be moveCursorToNextWordBoundary and moveCursorToNextSubwordBoundary.

We currently allow users to define editor.nonWordCharacters, which we use to build a word regex in Cursor::wordRegex (which should be renamed to Cursor::getWordRegex). We could allow users to define their own subword boundary regex. Presumably we'd use the end of the match, since JS regexes support lookahead but not lookbehind. We could also add the ability to fully customize the word regex for consistency. In both cases we'd provide a sane default.

[jspahrsummers]

@nathansobo That'd be awesome! Is there anything I can do to help?

[nathansobo]

@jspahrsummers Would you like to take a crack at it? It's probably easier to navigate than some of the vim-mode changes you've been looking at. I can't get to it with my full-time attention immediately because we have a long list of higher priority items.

[jspahrsummers]

I would… but I'm still struggling to find time for it. 😜

[dsandstrom]

I'll start adding support for this. However, what should the keymaps be? I was using q, which works great, but that would conflict with macros if they are ever added. I would like to use a single key, but there are no keys available that I know about.

[deiwin]

The vim plugin seems to sacrifice the comma. I don't know if that's the best idea, though.

[deiwin]

The \ and | characters seem to be available.

[jacekkopecky]

Just a thought - I could imagine a configuration option, or a per-language option somehow, for w and b to mind camelCase. Additionally, this setting could somehow affect the iw and aw text objects.

It's about time (and this might be the place) that someone reinvents the principles of modal text editing in the modern setting of windows, panes, big screens, widespread camelCase, colours, highlights and so on.

[deiwin]

This would probably mean that support for iW and aW should also be added to differentiate between the 2 possible meanings of a word. But I would probably like the uppercase versions to behave as the current lowercase versions do, instead of making them work as they currently do in vim (using the WORD definition).

Or maybe just have different bindings for all 3 cases. I mean, we have more modifier keys available than just shift.