]P does not paste over visually selected line

[GoogleCodeExporter]

What steps will reproduce the problem?
1.

Start up vim

vim --noplugin -u NONE

Execute the following sequece

iabc
def

if (true)
{
<TAB>ghi
}<ESC>gg2Y5jV]P

What is the expected output? What do you see instead?

I would expect the ghi line to be overwritten by the abc and def lines, and I 
would expect to see that the abc and def lines are indented to the level of the 
ghi.

Instead, I can see that the abc and def lines are put above the ghi line.

What version of the product are you using? On what operating system?

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Feb  3 2014 09:12:48)
Included patches: 1-161

Linux xxxxxx 2.6.18 #5 SMP Mon Jan 15 17:57:28 CET 2007 i686 Intel(R) Xeon(R) 
CPU            5130  @ 2.00GHz GenuineIntel GNU/Linux

Original issue reported on code.google.com by christ.v...@coosto.com on 3 Feb 2014 at 8:16

[GoogleCodeExporter]

I see the problem. The [p paste operation does not take care of visual mode.

Attached is a patch, that fixes the issue.

Original comment by chrisbr...@googlemail.com on 4 Feb 2014 at 10:26

Attachments:

• paste_bracket.diff

[GoogleCodeExporter]

I can confirm that this fixes my test case. But I wonder if the just 'cut' text 
shouldn't be put in the * register...

New test case:

vim -Nu NONE
iabc
def

if (true)
{
<tab>ghi
}<ESC>gg2Y5jV]PP

Expected:

abc
def

if (true)
{
    abc
    def
    ghi
}

Result:

abc
def

if (true)
{
    abc
    def
abc
def
}

Original comment by christ.v...@coosto.com on 4 Feb 2014 at 11:02

[GoogleCodeExporter]

Yes, you are right. Here is an updated patch. 

Original comment by chrisbr...@googlemail.com on 4 Feb 2014 at 12:03

[GoogleCodeExporter]

grrml, and for some reason, this stupid webinterface hasn't uploaded the patch.
Here is it again

Original comment by chrisbr...@googlemail.com on 4 Feb 2014 at 12:04

Attachments:

• paste_bracket_v2.diff

[GoogleCodeExporter]

I have a test case that breaks the behaviour:

vim --noplugin -u NONE

iabc
def

if (true)
{
<TAB>ghi
<TAB>jkl
}<ESC>gg2Y5j2V]P

Expected:
abc
def

if (true)
{
    abc
    def
}

Actual:

Expected:
abc
def

if (true)
{
    ghi
    abc
}

(in the P-buffer I have
    def
    jkl
, which is odd as well)

Original comment by christ.v...@coosto.com on 4 Feb 2014 at 12:51

[GoogleCodeExporter]

You are a good tester. ;)
Do you have some more tests?

Here is an updated patch, that seems to handle all mentioned use cases so far, 
and also does work correctly when using v_o. (I think, that patch deservers a 
test, whenever you can't break it anymore) ;)

Original comment by chrisbr...@googlemail.com on 6 Feb 2014 at 10:14

Attachments:

• paste_bracket_v3.diff

[GoogleCodeExporter]

You're welcome, I'm a software developer by trade and try to break as much as 
possible ;-)

The following is weird, don't know if it is explainable or a bug (since I don't 
use visual block mode often...)

vim -nU NONE
iabc
def

if (true)
{
<TAB>ghi
<TAB>jkl
}<ESC>gg<C-V>j$Y5j<C-V>j$]P

After that, I get the following:

abc
def

if (true)
{
|

}

| indicates cursor position.

If I do P and not ]P, I get:

abc
def

if (true)
{
abc
def
}

as expected

Original comment by christ.v...@coosto.com on 6 Feb 2014 at 11:13

[GoogleCodeExporter]

...slight change to my message above, I ran vim w/ an incorrect incantation, 
the result after ]P is:

abc
def

if (true)
{
}

(which I think is wrong as well, but not with 2 blank lines in there...)

Original comment by christ.v...@coosto.com on 6 Feb 2014 at 11:15

[GoogleCodeExporter]

Yeah, it should only delete, if you've used linewise visual mode. I am not 
sure, how Vim should behave, if you've used characterwise or block visual mode. 
So I left it as is and just make sure, Visual mode is ended and only in 
linewise visual mode delete the selected lines. Here is the pach.

Original comment by chrisbr...@googlemail.com on 8 Feb 2014 at 9:48

Attachments:

• paste_bracket_v4.diff

[GoogleCodeExporter]

With the last patch, I can confirm that ]P in visual block mode does not act as 
weird as it did before. Also (I just tested this...) using a count before the 
]P works as expected.

Last comment before I would advise this patch to be sent to Bram is that (IIRC) 
the indent-style is mixed tabs/spaces, and I think it should be space-only (?) 
(or at least not mixed...).

Original comment by christ.v...@coosto.com on 12 Feb 2014 at 9:05

[GoogleCodeExporter]

fixed by 7.4.199

Original comment by chrisbr...@googlemail.com on 2 Oct 2014 at 8:02

• Changed state: Fixed