In visual mode, the iw text object 'grows' with repeated presses of iw, ie., viwiwiw... will 'grow' to select multiple inner words.

However, this 'growing' behaviour is not seen when the cursor is placed on a single space. For example, pressing viwiw on

word1 word2 word3
     ^ <-- cursor

only selects the space (I expect 'word2' to be selected). This seems unexpected to me. Could this be a bug?

With multiple spaces, such as

word1   word2 word3
      ^ <-- cursor

the selection grows as expected.

(FYI, I am using gvim 8.1.2019, windows 64-bit)

  • v2iw grows over single space as expected. Also viw2iw works as viwiw should. So indeed it looks like a bug.
    – Matt
    Nov 2, 2019 at 17:42

1 Answer 1


Seems like it's working logically to me.

The docs (:h text-objects) give us three "rules":

  1. "a" commands: select "a"n object including white space
  2. "i" commands: select an "inner" object without white space OR just the white space
  3. the "inner" commands always select less text than the "a" commands.

There's also an unwritten rule that the selection should include already selected text (in our case the single character selected after hitting v). I think the behavior most users expect is selection expansion not selection replacement where some selected text is deselected. Certainly we don't want to do expansion in some cases and replacement in others.

Finally, one has to accept that iwiw is not the same as 2iw. The former is two atomic operations, the latter one. That is, as soon as we hit the first w in iwiw Vim acts before continuing to process our input. So we can't expect the two input sequences to always behave exactly the same way even if, in practice, they do for most circumstances.

Let's look at examples. When in visual mode, on a line with "The quick brown fox jumped..." then, (replacing spaces with "." just for readability"):

With the cursor somewhere inside quick

  • aw selects quick.
  • iw selects quick
  • 2aw selects quick.brown.
  • 2iw selects quick.

With the cursor on the space between quick and brown

  • aw selects .brown
  • iw selects .
  • 2aw selects .brown.fox
  • 2iw selects .brown

To follow the rules above there's really no other behavior possible for iw in the second scenario than remaining with a single space selected.

If instead selected text was:

.brown => violates "object without white space OR just the white space" rule as well as "selects less than aw"

brown => violates unwritten rule of not deselecting currently selected text (selection replacement)

Those are the only two alternatives that are remotely viable...and they don't follow the rules.

All of this is a (long winded) way of saying this is just a matter of having some simple rules with less-than-ideal behavior for one edge case.

  • @B Layer thank you for pointing out the technical details, in particular, the 'unwritten rule'. It seems that this 'unwritten rule' forces a visual selection to contain at least one character (ie. no empty selection). If selections are allowed to be empty, the expansion behaviors for iwiw and 2iw would be consistent in the edge case described, yes?
    – husB
    Nov 5, 2019 at 5:54
  • @husB Yeah, I think so. If it were the case that no text was selected at the time you entered Visual mode, but otherwise all rules were the same, then what you say should hold true.
    – B Layer
    Nov 5, 2019 at 20:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.