From be96fd2ae445526f4b2c6a256bc96b57dad811b6 Mon Sep 17 00:00:00 2001 From: John Passaro Date: Thu, 17 Nov 2016 12:36:11 -0500 Subject: inner-word selection excludes the next word See github issues #28 and #31. --- autoload/camelcasemotion.vim | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/autoload/camelcasemotion.vim b/autoload/camelcasemotion.vim index 505786d..9f3b598 100644 --- a/autoload/camelcasemotion.vim +++ b/autoload/camelcasemotion.vim @@ -121,7 +121,9 @@ function! camelcasemotion#Motion(direction, count, mode) " additional 'l' motion is appended to the motion; similar to the " special treatment in operator-pending mode. normal! l - elseif &selection != 'exclusive' && a:direction != 'e' && a:direction == 'ge' + elseif &selection != 'exclusive' && ( + \ (a:direction != 'e' && a:direction == 'ge') + \ || (a:mode == 'iv' && a:direction == 'w')) " Note_1b: " The forward and backward motions move to the beginning of the next "word". " When 'selection' is set to 'inclusive' or 'old', this is one character too far. @@ -129,6 +131,13 @@ function! camelcasemotion#Motion(direction, count, mode) " though, the forward motion finds the current "word" again, and would " be stuck on the current "word". An 'l' motion before the CamelCase " motion (see Note_1a) fixes that. + " Note_1c: + " A similar problem applies when selecting a whole inner "word": the + " cursor moves to the beginning of the next "word" which for an + " inclusive selection, at least in operator-pending mode, leads to + " counter-intuitive results. (See github issues #28 and #31.) The + " appended 'h' is needed in that case as well. Possibly for 'v' mode + " too. normal! h endif endif -- cgit v1.1