Closed matu3ba closed 2 weeks ago
Thanks for the suggestion!
I can reproduce. At first glance, it is indeed not a very good behavior. However, blockwise movement is kind of lesser tier of support for 'mini.move' because of how complicated it is to implement.
I'll look more into why this happens.
I've taken another look at this and it seems to work as expected.
It would be nice, if move_selection would have another mode so that a move is an actual swap of text elements freely into the buffer positions, so moving 1 upwards does
This is the core of the issue: 'mini.move' actually moves selection/line, not swaps. It may look like swapping when moving to the nearest neighboor (i.e. with v:count
1), but it actually is not. Here moving is more or less equivalent to "cut current selection -> move to target position -> paste selection". And provided diagrams show exactly this behavior.
My best suggestion is to use exchange gx
operator from 'mini.operators'. So in this case it would be something like:
gx
. The selection gets highlighted with MiniOperatorsExchangeFrom
highlight group (by default linked to IncSearch
).1v
. Important: make sure that new region and original "from" region do not intersect, as this will not get the result you'd expect.gx
again.Closing as not planned.
Contributing guidelines
Module(s)
mini.move
Description
Use case Drawing block selections up and down breaks right-wards indentation, which can make virtual edits for adjusting graphics unnecessary painful. I hope below drawings show the problem. Any kind of ideas would be appreciated.
Problem Description
got
want without redundant steps 1 box selection copy 2 selection replace whitespace 3 selection wanted position and paste
current behavior: 1 line selection movements dont work for multiple lines 2 minimove.move_selection up/down breaks right-hand intendation
It would be nice, if move_selection would have another mode so that a move is an actual swap of text elements freely into the buffer positions, so moving 1 upwards does
and moving 1 more upwards does
until
with the internal position of the collision range be kept. To me it looks like you have implemented collision detection, but nothing to keep track of correct fixups after nothig collides. For example, left and right movements have the same behavior: