[vim/vim] it behaves differently from i{ when spanning multiple lines (#1379)
xelra
When you use i{ on a code like this
function {
foo
bar
}
it will only select the inner lines foo and bar.
When you use it on a code like this though
<script>
foo
bar
</script>
it will select from > to <, same as if it were in one line.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
Bram Moolenaar
I can reproduce it. I wonder if changing to make it consistent would cause trouble for users who are used to the old behavior? I tend to think that "dit" should not delete the line break, thus work like "di{".
xelra
I think consistency over all.
Furthermore it's not just the linebreak. For example if the tag is already indented, then it will also select the indent on the last line right up to the closing tag. Also the linebreak on the opening tag is selected too. For example, if you try to indent the inner of the tag with vit>, the tags will also be indented, which is what should be expected of vat>. I think this behavior is a bug.
Tommy Allen
@brammool Would it be possible to treat this contextually? If I ran dit on this:
<tag>hello world</tag>
I would expect it to delete from > to < since I can just go back into insert mode and press <enter> (OTOH, if it worked like di{, I could just press <bs>). However, in HTML like this:
<tag> <!-- cursor here --> </tag>
I find myself wanting vitp to result in:
<tag> <span>pasted</span> </tag>
Not this:
<tag><span>pasted</span></tag>
I can fix the indent or join the lines in the former. But, it's much more tedious and annoying to break them into separate lines the latter.
geg-mopo3
vit means
Visual select Inside Tags
It doesn't say
Visual select Inside Tags except newline characters
So I would expect:
function {}
after di{ has been applied to:
function {
foo
bar
}
I recalled the other strange behavior when I read the topic. Not sure whether it has already been reported on this forum. I always wondered why vi<DELIMITER> didn't work with all the delimiters if they are placed on different lines. For example, it doesn't work with < and ".
asheq-svmx
I noticed the inconsistency as well.
Here's how i would precisely describe the current peculiar behavior of selecting an "inner bracket" (with i{ i( i[ or i<):
- If the opening bracket is followed immediately by a newline, the newline is not included
- If the closing bracket is preceded immediately by white space which is preceded immediately by a newline, the white space is not included (but the newline is)
I tend to think that we should simplify the behavior and just select all the characters (newlines and white space) unconditionally between the opening and closing brackets, which is technically precisely what the documentation implies.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.