Visual selection doesn't include leading white space on the first line

[chaoren]

Not sure if this is intentional or not, but...

Let ( ) denote the cursor position and [ ] denote visual selection.

Currently, you have this:

^    foo$             ^    [foo$
^    b(a)r$ -> vii -> ^    bar$
^    baz$             ^    baz($)]

I think it should behave like this:

^    foo$             [^    foo$
^    b(a)r$ -> vii ->  ^    bar$
^    baz$              ^    baz($)]

[chaoren]

Judging from the behavior of dii, I can conclude that this is indeed not intentional.

[qstrahl]

Okay, I can explain this.

Vim has three ways to select text in visual mode: linewise, charwise, and blockwise. When you use the indent text object from visual mode, I know which way you want to select the text; it's whatever visual mode you're in, line char or block.

When you use the text object as an operator, I have to make a guess about what you want. In most cases, when using it as an operator, linewise makes most sense. This explains the discrepancy between vii and dii.

The reason I decided not to have vii include the leading space is because I couldn't think of a case where it helps to do that. Any case where I would want the leading space, I'm performing a linewise operation; Vii is for that.

You could make the case that using ii in charwise visual mode should always put you in linewise visual mode, on the basis that ii is inherently a linewise text object, and other linewise text objects behave this way. If you feel strongly about it I could probably be persuaded to make that change.

[chaoren]

Actually, I just played around with a bit, and I think it's pretty neat that vii, Vii, and <C-V>ii can do different things.

My reasoning is that v<motion>d should behave exactly the same as d<motion>, and likewise, v<motion>c with c<motion>. For me at least, sometimes when I'm not certain of the reach of a motion, I'll enter visual mode to see exactly what I will be acting upon before issuing the d or c. I prefer that to d<motion>, find out I used the wrong motion, undo, d<other motion>, because you can usually issue multiple motions in visual mode to correct yourself.

I wonder if that equivalence is true in general for all vim a and i text objects, if it is, I think you should follow it too, just to be consistent. Otherwise, it's entirely up to your whim as the author of this project.

Hmm, sometimes there's a blank line difference between da<motion> and va<motion>d, but there's really no linewise text objects to set a precedent for this.

This was a dumb argument. I've nothing. ¯\_(ツ)_/¯

[qstrahl]

Actually, I just played around with a bit, and I think it's pretty neat that vii, Vii, and <C-V>ii can do different things.

Pretty much what it comes down to for me as well. I'll close this issue for now.