we all know what ci"
ci'
ci(
ci[
... does. Very handy in everyday's editing. I found something strange, and checked the help, didn't find out why.
say, I have a file:
foo "target" foo 'target' foo (target) foo {target} foo [target] foo <target>
if my cursor at the beginning of each line, (on the 'f
'), then I type ci", ci', ci(...
the cix
works only with quotes (single or double), doesn't work for brackets. why do they behave differently?
(dix
, vix
the same)
tested with --noplugin, vim 7.3
thank you.
Update
thanks @romainl for the answer. I still have doubt regarding the "pair processing in vim"
check this example:
foo "targ\"eti\" some\"thing else "
if I have a line like above, I type ci"
, no matter cursor is at beginning or between quotes, it works perfectly, it seems that vim does have the idea of "pair"?
and this maybe what you meant about the pairing ?
foo "target x some"thing else " foo (target x some(thing else )
I have above two lines, if (cursor at x
) I type ci"
and ci(
, nothing happened to 2nd line, but first line changed into:
foo "I"thing else " (I is cursor)
I would do “ci(”. Vim will search backward to find the first open paren, then search forward to find its match, and correct the text between (but not including) those characters.
In insert mode, Ctrl-o escapes user to do one normal-mode command, and then return to the insert mode. The same effect can be achieved by <ESC> ing to normal mode, doing the single command and then entering back to insert mode. Ctrl-i is simply a <Tab> in insert mode.
ci(
is consistent with ci[
, ci{
and cit
and all the other <action>i<something>
. Only ci'
and ci"
work like they do. The outliers are the quotes, here, not the brackets.
Vim doesn't consider that quotes come in pairs while brackets do. It has an internal logic for matching pairs that works with actual pairs but not with quotes hence the difference in behavior.
You are not the first to complain about that discrepancy: this is one solution, maybe you can find others.
edit
I don't have a deep knowledge of Vim's internals, unfortunately, so I can only make assumptions, here.
If you ask Vim to do ci"
it does its best to find a pair of double quotes but double quotes don't go by pairs: there's no way to tell if a "
is the closing one or the opening one contrary to brackets. Because of that, Vim must make some choices. IMO, the choice that would make the most sense considering how the other members of the family work, would be to assume that the cursor is between the quotes and select from the first one to the right to the first one to the left. I can only assume that this method proved wrong in some way or didn't work for some reason and that the other method (the current one) prevailed.
Another explanation could be that the i<something>
mechanism is somehow tied to a specific subsystem (maybe the same as showmatch
?) that is unable to deal correctly with quotes.
Anyway, just like you, I find this discrepancy weird and I've somehow internalized it and aligned my usage of <action>i"
to how the others work. To the point of actually doing 2t"ci"
or some variant instead of ci"
!! Inefficient, I know.
Did you read :h a'
? I completely forgot where I got my "limited understanding" of the issue but it was there! It says:
"Only works within one line. When the cursor starts on a quote, Vim will figure out which quote pairs form a string by searching from the start of the line."
What I get from that is this: for some reasons unknown to us, Vim uses another mechanism for matching quotes than for the other pairs and that is why ci"
is different from cib
and friends. The underlying cause is not clear at all but I'm fairly certain that the big picture looks a lot like what I imagine.
To me, it looks a lot like a bug or a limitation disguised as a feature.
If you are still curious, I'd suggest you ask any further question on vim-dev.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With