Open t9md opened 7 years ago
was not easy, so postpone until I get prepared. Noticed current subword movement is not ideal, lots of spaces to improve. I understand again, directly using atom's native motion not fit in vim like movement. But converting this native movement to vim-ish motion is a bit heavy. So postpone for now.
I like subword-motion so much that I even use it like this:
'atom-text-editor.vim-mode-plus:not(.insert-mode)':
'w': 'vim-mode-plus:move-to-next-subword'
'W': 'vim-mode-plus:move-to-next-smart-word'
'e': 'vim-mode-plus:move-to-end-of-subword'
'E': 'vim-mode-plus:move-to-end-of-smart-word'
'b': 'vim-mode-plus:move-to-previous-subword'
'B': 'vim-mode-plus:move-to-previous-smart-word'
:)
but is it possible to have it working with TextObject, like c i w
for "change inner subword"?
Also this https://github.com/t9md/dotfiles/blob/master/atom/keymap.cson#L317-%23L318
I can change subword by c d
. d
is mapped to inner-subword
in my keymap.
Without sacrifycing d d
, this granular scoped keymap gives us more freedom to tune keymap further effectively.
Now have default keymap
i d
is mapped to inner-subword
a d
is mapped to a-subword
d
is mapped to inner-subword
only in operator-mode, so you can do c d
to change inner-subwrodI've found subword movements in VMP to require too much keystrokes compared to what I'm used to. I've put together two regexes to emulate movements from CamelCaseMotion.vim: https://gist.github.com/romgrk/3ececed4cee93f4d77fbbb56461b987d
If you're interested in a PR to replace either subword or smartword with those ones, let me know I'll open one.
Below is a description of the movements, with cursor starting at |
:
dashh-case-word
snake_case_word
| ^ ^
w w
dashh-case-word
snake_case_word
| ^ ^ ^
e e e
XmlHTTPRequest
| ^ ^
w w
XmlHTTPRequest
| ^ ^ ^
e e e
We have existing motions below.
move-to-next-subword
move-to-previous-subword
move-to-end-of-subword
Could you explain your example movement explanation by comparing with those existing motion to make the point clear?
Sure, the difference is that the proposed motions land on what you're likely to be wanting to go. I'll take w
as an example: the current subword
behavior includes separator characters (-
and _
) as "words", therefore to move along those words takes many more keystrokes (double).
Current subword with dashes:
this-is-a-very-long-dash-case-word
| ^^ ^^^^ ^^ ^^ ^^ ^^
// We're landing on the '-' and also the character right after: bad!
Proposed subword with dashes:
this-is-a-very-long-dash-case-word
| ^ ^ ^ ^ ^ ^ ^
Current subword with underscores:
this_is_a_very_long_snake_case_word
| ^ ^ ^ ^ ^ ^ ^
// We're landing on the '_', but we usually want to go to the start of the actual word
Proposed subword with underscores:
this_is_a_very_long_snake_case_word
| ^ ^ ^ ^ ^ ^ ^
Current implementation simply use
cursor.subwordRegExp()
to get subword range and move to start or end of that wordrange.But spec fail in latest stable release 1.14.0.( This broken is really minor and no harm in actual use. )
But also noticed behavior diff vs native
editor:move-to-next-subword
. It's good for special care where to stop on snake_case_word in backward movement. So will improve to borrow good parts.What will changes
move-to-next-subword
and back bymove-to-previous-subword
.