[vim/vim] Wrong visual block when selecting wrapped part of lines after a linebreak (Issue #13300)
julio-b
Steps to reproduce
vim --clean +'set lbr' +'20vsp' - <<END aaaaaa bbbbbbbb cccccccc aa bbbbb ccccccccc ddddd END
:call feedkeys("2E\<C-v>lljr?")
undo, reselect the block and move the cursor to the opposite corner
:call feedkeys("ugvOr?")
Expected behaviour
Visual block replace should work like this:
bisected to v8.2.0147 03c3bd9
Version of Vim
since v8.2.0147
Environment
Operating System: Archlinux
Terminal: kitty
$TERM: xterm-kitty
shell: bash
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Hm, according to that bug, we need the following patch for replacing operator:
diff --git a/src/ops.c b/src/ops.c index aa6f4af37..54176b626 100644 --- a/src/ops.c +++ b/src/ops.c @@ -4274,6 +4274,7 @@ do_pending_operator(cmdarg_T *cap, int old_col, int gui_yank) // Restore linebreak, so that when the user edits it looks as // before. restore_lbr(lbr_saved); + get_op_vcol(oap, redo_VIsual.rv_vcol, FALSE); #endif op_replace(oap, cap->nchar); }
back then, we used redo_VIsual_mode, which would now correspond to redoc_VIsual.rv_mode but I don't think that was correct. I think it should have been the visual vcol instead I think.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
hm, no this breaks some tests
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
julio-b
Your patch works with this minor modification:
diff --git a/src/ops.c b/src/ops.c index aa6f4af37..ad6f0c12d 100644 --- a/src/ops.c +++ b/src/ops.c @@ -2275,10 +2275,6 @@ block_prep( char_u *prev_pstart; char_u *prev_pend; chartabsize_T cts; -#ifdef FEAT_LINEBREAK - // Avoid a problem with unwanted linebreaks in block mode. - int lbr_saved = reset_lbr(); -#endif bdp->startspaces = 0; bdp->endspaces = 0; @@ -2313,6 +2309,10 @@ block_prep( prev_pstart = cts.cts_ptr; MB_PTR_ADV(cts.cts_ptr); } +#ifdef FEAT_LINEBREAK + // Avoid a problem with unwanted linebreaks in block mode. + int lbr_saved = reset_lbr(); +#endif bdp->start_vcol = cts.cts_vcol; pstart = cts.cts_ptr; clear_chartabsize_arg(&cts);
@@ -4274,6 +4274,7 @@ do_pending_operator(cmdarg_T *cap, int old_col, int gui_yank) // Restore linebreak, so that when the user edits it looks as // before. restore_lbr(lbr_saved); + get_op_vcol(oap, redo_VIsual.rv_vcol, FALSE); #endif op_replace(oap, cap->nchar); }
For this particular case we need the effect of 'lbr' in block_prep, but as you said this breaks many tests.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Yeah, this is probably not the right way to fix it. I think it might be better to reset the cursor position in do_pending_operator instead.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Actually, I am not sure this is a bug. When an operator is pending, Vim internally disables the linebreak setting, otherwise the operations may work on different/unexpected selected regions.
So after you have visually block selected the region and pressed O you are basically back at selecting only the column going from line 1 down to line2, the column stays the same. That's also what is visible on the second window, where you will only see a single column selected.
E.g. after 2E\<c-v>lljO and pressing y to yank and end the visual selection, you can verify the column positions of the visual selection:
:echo string(getpos("'<")[1:2]) .. string(getpos("'>")[1:2])
It returns for me [1:24][2:24] , and since those two positions determine the size of the visual block, it seems like this is the correct behaviour.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
julio-b
Perhaps i didn't explain this correctly, when linebreak is enabled the user has no clue of what is actually being selected in a visual block.
Here is an example:
https://github.com/vim/vim/assets/16379308/154e84f0-58e1-46de-820c-aa5eb4f8055f
One might not expect that selecting a 2x1 block will replace a much bigger 2x13 block.
Also, selecting the same visual block differently (lefttop-rightbot vs righttop-leftbot) will have extremely different results:
https://github.com/vim/vim/assets/16379308/8e37e4d8-4d30-4c1c-8b5f-2f119d950506
There is no way to predict the end result just by looking at the visual block. Although the '< ,'> marks are different, the visual representation is still the same, which is a bit confusing. Would you agree?
I'm not sure what is the expected behavior here, because some operations should reset 'lbr' while others should not. I will close this issue for now, because fixing this will require a lot of changes an it's more trouble than it's worth.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
julio-b
Closed #13300 as not planned.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.